КОМПЬЮТЕР-ИНФОРМ Главная страница || Статьи 11'2003 (16 - 29 июня) || Новости СПб || Новости России || Новости мира
Компьютер-Информ || Архив || Рубрики || Поиск || Подписка || Работа || О "КИ" || Карта
24-25 июня
Конференция ИТ в машиностроении и судостроении
В. И. Куперштейн, ФГУП Адмиралтейские верфи
Современные представления об инструментарии управления производством включают
такие компоненты, как управление проектами и методы управления производством
и запасами (ERP).
Особенность судостроения заключается том, что в этой отрасли роль перечисленных
методологий в судостроении оценивается как сопоставимая.
Характеризуя область предпочтительного применения методов ERP, можно считать,
что применительно к судостроению эта область охватывает внутрицеховое управление,
а также управление материальным обеспечением производства по большинству позиций
и по изделиям собственного изготовления.
В свою очередь область применения методов управления проектами в судостроении
можно охарактеризовать более широко:
- управление постройкой заказов;
- управление подготовкой производства;
- управление поставками основного оборудования;
- управление предприятием на межцеховом уровне.
При этом сетевые графики постройки заказов определяют производственный план
для всех подразделений верфи, внутреннее планирование которых основывается на
принципах ERP. Такое использование сетевых графиков постройки заказов обеспечивает
целостность управления верфью.
Опыт показывает, что применение методов управления проектами на верфи оказывает
влияние на такие важные компоненты управления, как:
- организация подготовки производства;
- материальное обеспечение производства;
- методы управления производством;
- организация управления;
- система управленческого учета;
- корпоративная информационная система предприятия.
Характеризовать влияние методов управления проектами на подготовку производства
верфи можно, прежде всего, за счет следующих факторов:
- переход к разработке комплексных графиков постройки заказов вместо совокупности
частных графиков;
- замена выпуска планово-учетной документации по видам работ на основе выпущенных
чертежей разработкой фрагментов графиков;
- введение принципиально новой формы организации подготовки производства на
основе строительной стратегии.
Разработка комплексных графиков постройки заказов обеспечивает целевое управление
подготовкой производства, формирует процессно-ориентированный подход к подготовке
производства, естественный способ увязки планов разных подразделений независимо
от их подчиненности.
Замена выпуска планово-учетной документации разработкой фрагментов сетевых графиков важно тем, что позволяет перейти от описания технологии в планово-учетной документации к формированию системы контролируемых и управляемых промежуточных продуктов законченных результатов работ. Но это требует соответствующего перераспределения ответственности специалистов: традиционно они отвечают за отдельные виды работ, тогда как в современных условиях необходима ответственность за законченный результат работ.
При всей сложности таких преобразований это создает предпосылки для создания
эффективной системы управления затратами, и в первую очередь затратами труда.
Так как при использовании методов управления проектами основным инструментом
планирования становится сетевой график, то его разработка одна из важнейших
задач подготовки производства. При разработке графика оказывается необходимым
проанализировать большой объем данных, рассредоточенных по разным документам,
которые разрабатываются разными службами в течение достаточно большого интервала
времени. Эти данные на практике достаточно трудно собрать и еще сложнее обеспечить
их непротиворечивость. В практике мирового судостроения сложился метод организации
подготовки производства, при котором важнейшим документом становится так называемая
строительная стратегия.
Строительная стратегия представляет собой комплект документов, формирующих
исходные данные (организационные, плановые, инженерные) для разработки сетевого
графика постройки заказа на основе доступной в данный момент времени информации.
Распространяется строительная стратегия по всем подразделениям, участвующим
в постройке заказа и его обеспечении. Этот документ обычно разрабатывается в
нескольких редакциях, каждая из которых соответствует определенному уровню определенности
данных о строящемся заказе. В целом можно сказать, что строительная стратегия
объединяет согласованные между собой документы, необходимые для уверенной и
объективной разработки сетевых графиков постройки заказов, организации выполнения
работ. Так как методы использования и разработки сетевых графиков на каждой
верфи свои, то единого стандарта строительной стратегии не существует. Осоставе
этого документа можно судить по принципиальной схеме, приведенной на рис. 1.
Комплекс перечисленных факторов влияния методов управления проектами на подготовку
производства обеспечивает возможность повышения ее качества и эффективности
производства.
Управление проектами позволяет способствовать экономии средств за счет затрат на материально-техническое обеспечение. Этого можно достигнуть за счет обоснованного определения сроков основных поставок (наиболее дорогих и влияющих на формирование корпуса), а также за счет контроля сроков получения установочных данных поставщиков, что совершенно необходимо для своевременного изготовления фундаментов.
Для этого требуется наработка и включение в состав сетевых графиков постройки
заказов типовых фрагментов основных поставок, а также создание системы планирования,
введение планирования основных поставок и отчета по их исполнению. Как указывалось
ранее, применительно к условиям судостроения системы управления проектами не
в состоянии обеспечить управление поставками основной номенклатуры материалов
в этой области наиболее эффективного использовать ERP-системы.
Но даже с учетом сказанного применение систем управления проектами позволяет
более уверенно управлять оборотными средствами предприятия.
Влияние методов управления проектами на технику управления производством в
судостроении можно рассматривать как ключевой фактор. Системы управления проектами
в лучшем смысле слова навязывают передовые методы управления. Это обеспечивает,
в частности:
- переход к номенклатурно-календарному планированию, что обеспечивает возможность
планировать конкретные сроки выполнения работ. Это создает основу системы непрерывного
планирования, создает предпосылки для сокращения плановых циклов постройки судов
и повышения эффективности использования наиболее дефицитных производственных
мощностей;
- создание условий для отказа от затратных методов управления, ориентируя производственный
персонал на достижение результатов, а не на затратные показатели;
- качественное повышение прозрачности состояния производства, позволяя контролировать
производство постоянно, а не только в моменты окончания плановых периодов, быстро
выявлять обман и ошибки в отчете о результатах работ;
- оперативное и объективное прогнозирование состояния производства на основе
методики освоенного объема;
- введение методов планирования и управления подготовки и обеспечения производства
наравне с работами производства. Это позволяет эффективно управлять окружением
проекта, значительно повышая вероятность его успешной реализации.
Внедрение методов управления проектами на отечественных верфях сталкивается с типовыми проблемами, вызванными тем, что еще десять-двенадцать лет назад схемы управления всеми отечественными верфями были типовыми. Поэтому даже организация управления, еще сохранившаяся на большинстве верфей, серьезно противоречит современным методам управления. Существующая организация в большинстве случаев является функциональной и не ориентирована на конечный результат. Поэтому на многих верфях при существующей организации управления ответственность за управление производством размыта.
Внедрение методов управления проектами требует отработки и внедрения процессной
организации управления, включая:
- централизацию ответственности на уровне верфи,
- децентрализацию управления на внутрицеховом уровне.
Принцип схемы управления судостроительным производством, ориентированной на
применение методов управления проектами, может быть проиллюстрирован при помощи
рис. 2.
Есть основания полагать, что такая схема распределения обязанностей, ответственности
и прав в рамках единой плановой службы верфи будет создавать условия для эффективного
управления производством, сокращения численности управленцев и улучшения условий
их труда.
Важной особенностью внедрения систем управления проектами на любой верфи является
ее влияние на систему управленческого учета. Например, традиционно в отечественном
судостроении основные затраты труда на постройку заказа, затраты труда на оснастку,
на уборку заказов и несение вахт относили на разные бухгалтерские заказы. Так
же обычно строится и управленческий учет.
Именно внедрение систем управления проектами, каждая из которых является готовым
инструментом управленческого учета, показывает необходимость интеграции в сетевом
графике разных видов затрат и показывает естественные пути для этого, что можно
рассматривать как первый шаг к формированию отвечающей современным требованиям
системы управленческого учета и необходимых для ее функционирования стандартов.
Применение систем управления проектами оказывает существенное влияние на развитие корпоративной информационной системы, создавая надежную платформу для поддержки управления производством современными информационными технологиями. Многие системы управления проектами работают в средах таких современных СУБД, как Oracle. Это позволяет напрямую получать данные из таблиц системы управления проектами и даже вносить в них изменения. Часто это провоцирует руководителей и специалистов информационных служб на разработку программного обеспечения, предназначенного для улучшения признанных на мировом уровне систем управления проектами, прежде всего путем приспособления к существующим формам управления. Но в этом влиянии есть серьезная опасность подмены совершенствования методов управления при помощи современных информационных технологий ритуальными действиями, только обозначающими планирование.
Поэтому наиболее перспективно внедрение хорошо зарекомендовавших себя в мировой практике систем управления проектами именно как стандартных компонентов корпоративной информационной системы.
Юрий Корельский, зам. начальника ОАСПУ ФГУП Адмиралтейские верфи
При создании информационной системы предприятия существуют некоторые стандартные проблемы. В этой статье я попытался классифицировать их, основываясь на собственном опыте, а также огромном опыте моих коллег из отдела автоматизации ФГУП Адмиралтейские верфи.
Типичные проблемы
Стихийное развитие
Как правило, развитие информационной системы предприятия на первом этапе происходило
достаточно стихийно. Исторически, вычислительная техника закупалась в первую
очередь для решения задач бухгалтерского учета (как правило, создавался ВЦ)
и для решения задач проектирования. Причем, в ВЦ работали специалисты именно
в области информационных технологий, а в проектировании молодые перспективные
ребята, но имеющие инженерно-конструкторское образование.
ВЦ со временем развивался в отдел АСПУ, а отдел проектирования обрастал собственным
бюро, занимающимся задачами от простого сопровождения средств ВТ до разработки
программного обеспечения. Таким образом, происходила децентрализация процесса
автоматизации.
Децентрализованное управление
Как следствие децентрализации самого процесса, управление им также складывалось
не лучшим образом. Извечный конфликт ВЦ и ИЦ приводит, как правило, к возникновению
систем, частично дублирующих друг друга и дополнительных проблем по интеграции
данных. Несмотря на эти проблемы, обе службы считают отказ от своей системы
политическим проигрышем, поэтому цепляются за нее до последнего.
При этом отсутствует человек, отвечающий за процесс автоматизации вообще, вычислительная
техника закупается для подразделения или для человека, а не для решения конкретной
задачи, вопросы не решаются в комплексе.
Чтобы проиллюстрировать это, приведу один пример. Закупаются в отдел снабжения
компьютеры с принтерами. Из соображений экономии, принтеры берутся струйные.
При этом внедряется параллельно еще одна задача, которая подразумевает большой
объем печати (печать требований). После нескольких месяцев эксплуатации все
понимают, что струйные принтеры не удовлетворяют потребностям из-за низкой скорости
печати и больших расходов, связанных со стоимостью чернил и ремонта. Поэтому
закупаются лазерные принтеры формата А4 на почти каждое рабочее место. Чуть
позже, для решения третьей задачи, создается локальная сеть и покупается принтер
формата А3, так как эта задача требует именно такого формата печати. А теперь
давайте сосчитаем выброшенные деньги: струйные принтеры раз, половина лазерных
принтеров формата А4 два. Если бы к этому вопросу сразу подошли централизованно,
правильно было бы форсировать создание сети, закупить 12 скоростных принтера
формата А3 и несколько принтеров А4 для печати документов.
Отсутствие единой цели
При создании любой системы (не только информационной) зачастую под целью понимается
что-то типа повышение качества/скорости/объема выполняемых работ. То есть,
для повышения качества конструкторской документации и скорости корректировки
чертежей. Но имеет ли смысл повышать эту скорость? Предположим, существуют
два инженера, специалиста по трубопроводам. По старой технологии они работали
по 46 часов в день и выполняли требуемый объем работ. После внедрения системы
А, производительность труда повысилась на 50 %. Какой экономический эффект
может быть получен от внедрения? Если не произошло каких-то изменений вне данного
бюро, то внедрение привело к убыткам, так как уволить одного инженера нельзя:
отпуск, болезнь и т. п. это слишком большой риск. Уменьшить заработную плату
тоже нельзя, так как это психологически подорвет всякое желание осваивать новые
технологии вообще. Поэтому эти инженеры просто будут в два раза меньше работать,
но при этом сопровождение (не говоря уже о покупке) данной системы будет стоить
соответствующих денег.
Я считаю, что подход повышение качества/скорости/объема выполняемых работ
в корне неверен. Единственной целью (за исключением, может быть, благотворительности)
является повышение конкурентоспособности предприятия. И уже подцелями будут
и снижение трудоемкости, и снижение затрат, и все остальные цели.
Так как данная цель не рассматривается, или (в лучшем случае) рассматривается
как что-то абстрактное и недостижимое, то информационная система развивается,
основываясь на сиюминутных выгодах или желаниях. Поэтому затраты на нее превышают
необходимые в 510 раз. Любое внедрение должно приводить именно к повышению
конкурентоспособности. Если это, предположим, повышение качества, то надо определиться,
приведет ли это повышение к увеличению спроса, снижению гарантийных издержек,
и в каком количестве. Нельзя забывать о том, что заработную плату выплачивает
не начальник отдела и не генеральный директор, а конечный потребитель. И любые
изменения продукции, приводящие к увеличению себестоимости, должны рассматриваться
в ракурсе готовности потребителя платить за них из своего кармана.
Человеческий фактор
В создании любой системы далеко не последнюю роль играет человеческий фактор.
Под этим я подразумеваю именно те желания, о которых упоминал в предыдущем пункте.
Если руководитель высокого уровня приехал в соседнюю организацию, и там ему
показали что-то красивое, пусть и не имеющее практического смысла, достаточно
вероятно, что, возвратившись, он спросит: А у нас такое есть?. И, скорее всего,
перед ИТ-службой будет поставлена задача создать/купить/внедрить что-то подобное,
чтобы не быть хуже. При этом процесс автоматизации делает настолько замысловатые
петли на пути к светлому будущему (так как эту систему приходится потом использовать),
что скорость этого движения тоже понижается в разы.
При этом бюджет ИТ ограничен, и вместо жизненно необходимых для развития вложений,
деньги вкладываются во второстепенные задачи.
Но информационная система и наличие компьютера на рабочем месте могут сыграть
свою роль в удержании персонала. Большинство молодых специалистов считает наличие
компьютера на рабочем месте одним из необходимых условий для работы. Вполне
возможно, что молодой специалист согласится работать за меньшие деньги, но с
компьютером, так как это ускорит его профессиональный рост. И это эффект, который
можно посчитать.
К сожалению, при закупке компьютеров, установке нового программного обеспечения
и т. п. часто совершенно не рассматривается вопрос сопровождения. Даже закупка
программного обеспечения должна быть сбалансирована. Например, Microsoft Office,
наверняка, установлен на большинстве компьютеров. А используется исключительно
Microsoft Word для написания служебных записок и приказов. Но существует множество
бесплатных средств (тот же WordPad), с помощью которых функционально можно выполнить
те же действия. В редчайших случаях можно воспользоваться 12 лицензиями Microsoft
Office, установленными на терминальном сервере для создания презентации или
расчета в Excel. Но поскольку закупка (или отказ от закупки) ПО никак не отражается
на конечном пользователе, то он абсолютно не заинтересован в экономии. Если
подойти к инженеру и предложить отказаться от того же Microsoft Office за прибавку
к зарплате в половину его стоимости, 99 % с радостью согласятся, и будут выполнять
ту же работу, но другими средствами.
Наследуемые системы
Конечно же, любое предприятие с большой историей имеет множество систем, которые
уже созданы и прекрасно функционируют, но не отвечают современному подходу к
информации. Эти системы тормозят развитие, так как создать realtime-интерфейсы
для работы с ними новых систем практически невозможно, модифицировать их в рамках,
например, изменяющегося законодательства также невозможно, так как люди, создававшие
эти системы, уже на пенсии. Но если не развивать информационную систему, они
прекрасно существуют и работают.
Вопрос с наследуемыми системами достаточно широк, и при акционировании, когда
происходит смена руководства ИТ-службы, сложность анализа для принятия решения
о дальнейшей судьбе таких систем и пути их развития часто приводит к полному
отказу от них, т. е. к закупке новой современной системы, но с полной документацией,
сопровождением и четкими перспективами развития.
Непонимание руководства
С позиции руководителя старой закалки, работающего по протоколам, бумажным
планам и т. д., совершенно непонятно, почему служба ИТ имеет такой огромный
бюджет, которого все равно не хватает. Сделать красивый документ вместо обычного
и распечатать на цветном принтере стоит действительно немного. Но это непонимание
происходит, с моей точки зрения, по вине исключительно службы ИТ, которая не
может донести до руководства (а иногда даже сформулировать) задачи, перспективы
развития и объяснить что же это все-таки дает. Поэтому бюджет службы утверждается
полулегальными методами, а развитие происходит скачкообразно. Именно поэтому
закупается техника в тех количествах, которые дают, а не столько, сколько надо,
так как потом могут и не дать денег.
Пути решения
Решений этих проблем по отдельности достаточно много, но они не дают должного
эффекта. Для успешного развития информационной системы необходимо в первую очередь
сформулировать для руководства предприятия цель. При этом неправильно говорить,
что если мы сейчас не вложим деньги в ИТ, то через три года наше предприятие
будет неконкурентоспособно. Данный подход напоминает шантаж и будет воспринят
руководством в штыки.
Необходимо сформулировать и показать несколько стратегий развития предприятия,
среди которых будет стратегия стагнации. То есть, не вкладывать денег в развитие,
но даже в этом случае бюджет будет не нулевым, так как необходимо поддерживать
существующую систему.
Эта стратегия является одной из ключевых, и должна быть обязательно проработана,
так как в случае финансовых проблем предприятия руководство должно представлять
минимум бюджета ИТ.
Любые увеличения бюджета относительно этого минимума должны давать повышение
конкурентоспособности предприятия. При этом осью измерения этого уже может быть
и снижение трудоемкости, и уменьшение цикла выпуска изделия, и уменьшение издержек.
Руководство должно осознанно вкладывать деньги в информационную систему, но
обязательно при этом знать, что именно будет получено в результате.
При этом нельзя забывать о возникновении синергетического эффекта, когда внедрение
нескольких систем вместе может давать эффект больший, чем просто сумма этих
эффектов. Более того, некоторые системы не дают никакого или даже дают отрицательный
эффект по отдельности.
Заключение
Я осознанно не остановился на технических проблемах, так как существует множество компаний, которые специализируются на их решении. Главное в создании информационной системы четко знать цель, иметь согласие руководства на стратегию и право на принятие тактических решений. Иидеальной постановкой задачи был бы в этом случае текст договора с руководителем проекта по созданию шаттла: Правительство США обязуется финансировать проект в размере ххх долларов, а руководитель проекта обязуется запустить шаттл ххх числа.
ОАСПУ ФГУП
Адмиралтейские верфи
e-mail: yuri@ashipyards.com
Тел.: +7(812) 114-8500
Факс: +7(812) 114-8885
Кучерявых В. М., начальник управления ИС, канд. физ.-мат. наук
Музычук И. А., начальник отдела ИТ
Сопов М. В., главный специалист по САПР ОАО МЗ Арсенал
1. Необоснованные ожидания интеллектуальности в ИТ-системах
Сам компьютер интеллектом не обладает, он может только то, чему его научил
человек.
В определенных инженерных, а более точно, конструкторско-технологических кругах
бытует мнение, что компьютерные технологии могут все, но злые программисты
не хотят открывать своих профессиональных секретов.
По-настоящему, мы все прекрасно знаем, что это не совсем так, а точнее совсем
не так.
Просто современный конструктор/технолог, имеющий дело с программным обеспечением
(которое может быть прекраснейшим инструментом проектирования), должен знать
хотя бы основы алгоритмики.
Ведь никто, кроме самого пользователя (в нашем случае инженера) не может грамотно
настроить (или, на худой конец, подсказать, как настроить) свой инструмент.
Нужно только этот инструмент хорошо знать и уметь им пользоваться.
И только тот, кто его знает плохо, и не хочет учиться, станет катить бочку
на инструмент и его разработчиков.
В качестве аллегории хочется привести фантастический пример: на N-ском кораблестроительном
заводе существует некое КБ, а также служба поддержки пользователей. Но дело
в том, что в КБ нет компьютеров, все проекты выполняются конструкторами на ватмане,
при помощи кульманов, линеек, циркулей, карандашей и других чертежных принадлежностей.
И вот когда необходимо изменить угол наклона кульмана, заточить карандаш, и
т. п., конструктор пользователь чертежной принадлежности вызывает мастера-настройщика
из службы поддержки. Все довольны.
Понятно, что таких ситуаций не бывает. Но таких ситуаций не должно быть и в
том случае, когда в КБ используется специализированное ПО, установленное на
клиентском рабочем месте, не правда ли?
2. Инженер должен быть немножко программистом. Алгоритмы проектирования
Зависимости между операциями в дереве. Зависимость последующих от предыдущих,
и наоборот. Параметрическое проектирование.
Формализация операций, выполняемых инженером при работе в ИТ (три типа операций
Создать, Выбрать, Оформить).
Инструмент для описания процессов.
На сегодня не является секретом тот факт, что всякий мало-мальски объемный инженерный
(конструкторско-технологический) проект не может вестись в одиночку и требует
координированных усилий со стороны команды разработчиков. А поскольку всякий
такой проект имеет иерархическую структуру или, иными словами, представляет
собой дерево подпроектов (например, узлов, подсборок), то и команда проектантов
строится по иерархическому принципу: кто за какую подветвь дерева отвечает
и, соответственно, кому подчиняется. Принцип формального подчинения становится
принципом делегирования работы сверху вниз. Чем ниже разработчик находится в
этой иерархии, тем более узкие и специализированные задачи он решает.
Но сначала дерево проекта должно родиться в голове главного его архитектора
(конструктора, технолога). После этого это дерево начинает расти совместными
усилиями участников команды, каждый из которых выращивает свою ветку (проектирует
узел, процесс его сборки и т. п.). Ветки дерева заканчиваются листьями (например,
проектами деталей, небольших сборок), за каждым из которых закреплен свой разработчик.
И если взглянуть внимательнее, то мы увидим, что его работа опять же строится
по принципу дерева, ибо он занимается ни чем иным, как выстраиванием очередности
действий или операций, т. е. построением дерева. Все операции, равно как и
объекты (узлы) в дереве, связаны зависимостями, как прямыми, так и обратными.
Зависимости или связи могут быть вертикальными или горизонтальными, сильными
или слабыми, но, самое главное, все они подчиняются некоей общей алгоритмической
логике проектирования. И у этой логики на сегодняшний день есть весьма развитый
язык язык информационных технологий, владение которым является необходимым
(но отнюдь не достаточным) условием успешного проектирования. Достаточным же
условием будет способность инженера (конструктора, технолога) изложить на этом
языке и передать другим (в том числе и программному обеспечению) свои знания,
умения и опыт.
Однако, как говорилось выше, любой реальный проект являет собой достаточно
большое, разветвленное дерево, которое состоит из узлов, связанных между собой,
в основном, зависимостями предокнаследник. Понятно, что при осуществлении
такой связи наследуются многие параметры и свойства узла-родителя (да и всей
надветки). Значит, дочерние узлы напрямую зависят от родительских.
Но давайте предположим, что в процессе проектирования оказалось, что, исходя
из свойств последнего дочернего узла, необходимо существенно поменять (перепроектировать)
узел-прапрапрародитель (т. е. находящийся на несколько уровней наследования
выше), это называется итерация. То есть, узлы-предки опосредованно зависят
от узлов-наследников. И здесь очень важно не прервать линию преемственности.
Повторимся: эта задача решается путем грамотного использования разработчиком
языка проектирования при совершении операций над деревом.
Какие же операции совершает каждый разработчик? Условно их можно разбить на три вида: Создать, Выбрать и Оформить. Первый из них составляет саму сущность проектирования, второй имеет отношение к повторному использованию накопленного коллективного опыта (оформленного на физическом уровне как выбрать из базы данных), третий дает возможность опубликовать результаты своей деятельности в виде документа. Наложим на них умение ветвить действия по условию, циклически их повторять и, наконец, параметризовать или оформлять в виде процедур (это уже высший пилотаж), и мы получим схему работы, которая может быть описана как некий процесс. Дело остается за малым выбрать инструмент для описания этого процесса, а таких инструментов современный рынок предлагает достаточно много.
3.Распределенный опыт инженеров что это такое?
Базы данных в головах и на бумаге
Формализация неформализованных знаний. Необходимость знаний азов алгоритмики
у современного инженера.
Опосредованная передача опыта, минуя связку учительученик. Публикация индивидуальных
знаний.
SmarTeamTechCardVBA эффективный инструментарий управления знаниями и данными.
Человечество всегда волновала проблема преемственности. Не будь ее, никто бы
не стал изобретать заново велосипед или колесо. Но на самом деле, если приглядеться,
эта проблема тоже является проблемой языка языка, на котором происходит передача
знаний. Здесь очень важно договориться о базовом наборе аксиом-терминов, лексике
(словарном запасе составных терминов) и синтаксисе (правилах манипулирования
терминами).
В докомпьютерную эпоху передача опыта от наставника к ученику осуществлялась
на вербально-эмпирическом уровне (смотри и учись, Вася!), и эффективность
передачи сильно зависела от способности наставника и ученика негласно договориться
о терминах и правильно формулировать вопросы и ответы. При этом прямые, формализуемые
знания передавались с искажениями, а неформализуемые на подсознательном уровне,
и качество их передачи можно было оценить только по завершении обучения (да
и то не всегда). Это наследие породило одну из наиглавнейших проблем передачи
опыта сегодня: сегодняшние наставники учились до компьютеров, а сегодняшние
ученики начали учиться с применением ПК. Осуществить и настроить связь по передаче
опыта между ними это основная наша задача. Для этого необходимо формализовать
и обезличить по возможности максимальный объем опыта и знаний. Вот проблема-то!!!
В принципе, любое знание (опыт) можно формализовать алгоритмическими конструкциями
если-то и перейти к, и если задуматься, то мы постоянно пользуемся этими
конструкциями. Наставнику, пытающемуся формализовать свой опыт, необходимо осознать
весь его объем и структуру. По-настоящему, это не так легко (в первый раз),
но и не так уж сложно (если это хотя бы раз уже проделано). Вот здесь и может
очень и очень пригодиться интуитивное знание алгоритмики.
Выше было сказано об обезличивании опыта. Информационные технологии предлагают нам для этого изумительные по действенности инструменты и методологию их использования. Например, базы данных формализованные знания и ресурсы общего доступа (телеконференции) неформализованные знания, а также инструменты по сбору знаний и их формализации (например, шлюз телеконференция база данных).
Зададим теперь себе вопрос: что же должно явиться результатом такой формализации знаний и опыта? Очевидно, новый инструмент, который позволил бы конструктору/технологу эффективно управлять формализованной информацией для более чем успешного (на порядок успешнее, чем раньше) решения поставленных перед ним задач. И такие инструменты на сегодняшний день существуют и уже используются на отечественных машиностроительных предприятиях. К числу этих предприятий относится и ОАО МЗ Арсенал, где силами отдела информационных технологий при поддержке других служб реализуется проект по разработке и внедрению системы конструкторско-технологической подготовки производства на базе объектно-ориентированной PDM-системы SmarTeam (системы управления инженерными данными), твердотельно-ориентированной 3D CAD-системы SolidWorks (системы конструкторского проектирования) и реляционно-ориентированной CAT-системы TechCard (системы проектирования технологических процессов). В качестве программного интерфейса между ними и основного средства кастомизации (от англ. customize настраивать, усовершенствовать) выступает среда разработки VB (Visual Basic), но в принципе может быть использован любой другой инструментарий, поддерживающий платформы COM и .NET.
4. Конструктор технолог. Возможно ли взаимодействие без потерь? 3D CAD-система: Parasolid ядро, объединяющее инженеров
Потоки данных в связке инженер-конструкторинженер-технолог.
Разделение типов данных геометрияресурсы.
Взгляд на данные с различных точек зрения. Объединение данных в единой модели.
Последовательное доопределение данных в потоке.
Использование SolidWorks как посредника между СУБД.
Роли участников проекта (строителей дерева) различны, но основные садовники
это конструкторы и технологи, причем, если пользоваться терминологией 3D CAD-систем,
то конструкторы, как правило, наращивают материал проектируемой детали, а технологи,
наоборот, снимают материал с заготовки до получения искомой детали. Понятно,
что имеются в виду виртуальные деталь, заготовка, и, соответственно, материал.
Для того, чтобы технолог мог максимально эффективно использовать данные, полученные
от конструктора вместе с файлом детали, конструктор должен передать технологу
информационно целостный и логически здоровый файл детали/сборки. Имеется в
виду, что, во-первых, технолог должен получить только необходимые ему для работы
данные (материал, чистота поверхности, допуски и т. п.) все остальное должно
быть отфильтровано; во-вторых, должны передаваться только необходимые и достаточные
данные о допусках, чистоте поверхности и т. п.; в-третьих, структура детали/сборки
(дерево) должна быть максимально проста и интуитивно понятна (логически здорова).
Мало того, в случае итераций в процессе передачи детали/сборки технологу (когда
технолог выставляет требования к узлу, конструктор выполняет их, а у технолога
опять возникают вопросы, и т.д.) также немаловажно качество передаваемых данных
и минимизация их потерь.
Данные, циркулирующие между конструктором и технологом, можно разделить по принципу
формасодержание, геометрияматериал или что сделаноиз чего сделано.
Оба вида данных в отрыве друг от друга являются чистой абстракцией, и только
совмещение их в определенной комбинации дает информацию о конкретном объекте
(детали, заготовке и др.). На языке материалов эти наборы данных (атрибутов)
называются сортаментами и марками. Каждый сортамент описывает некоторую совокупность
геометрических свойств (размеров, допусков), каждая марка некоторую совокупность
физических и химических свойств материала (плотность, химический состав, тепловые
и магнитные свойства, стойкость к коррозии). Мы не говорим о таких свойствах,
как цена, поставщик и т. п. они становятся актуальными при активизации других
процессов, больше имеющих отношение к логистике.
На стыке сортамента и марки возникают новые наборы атрибутов (механические свойства,
твердость, вид поставки сортамента из данной марки). Различные виды и режимы
обработки вносят сюда свою лепту. Таким образом, модель данных усложняется все
больше и больше, и в данных можно утонуть.
Здесь единственным выходом является последовательно проводимый принцип классификации
и идентификации описываемых объектов. Его основные постулаты:
1. объекты разбиваются на классы, образуя дерево наследования;
2. атрибуты делятся на общие и специфические, и в соответствии с этим относятся
к более общим классам или подклассам;
3. связи между объектами тоже образуют классы и имеют свои атрибуты;
4. выделяется ряд атрибутов, используемых в качестве строительных блоков для
обозначения объектов, и описываются правила построения идентификаторов;
5. атрибуты делятся на смысловые группы в привязке к потребностям конечных
пользователей. Этого вполне достаточно для того, чтобы получить четко структурированные
и легко фильтруемые потоки необходимых данных.
Фильтрация данных дает пользователям возможность взглянуть на них с различных
(индивидуальных) точек зрения. Идентификация по вышеописанным правилам позволяет
извлечь максимум нужной информации только из обозначения. Сочетание этих принципов
дает синергетический эффект: 1. можно отображать в обозначении только те атрибуты,
которые интересуют текущего пользователя; 2. можно доопределить обозначаемый
объект новыми специфическими атрибутами и отобразить их в идентификаторе. При
этом и волки сыты, и овцы целы: данные живут в единой целостной модели по
своим законам, и в то же время пользователи довольны, ибо видят то, что хотят,
и одновременно видят то, что должны.
В качестве писателей и читателей данных могут выступать не только люди, но и приложения, умеющие это делать (например, SmarTeam и TechCard). Данные можно передавать в теле файла, например, модели SolidWorks, убивая тем самым двух зайцев: 1. передавая учетную информацию из базы данных; 2. передавая смысловую информацию, содержащуюся в самой модели, которая также необходима ее получателю. Если должным образом настроить эту процедуру, то, как показывает опыт, сами приложения, в которых ведется проектирование, становятся прекрасными помощниками для конструкторов и технологов, избавляя их от множества рутинных операций, связанных с повторным вводом и, как следствие, неизбежных ошибок.
5. Хранить ли одни и те же данные в разных местах? Проблемы импорта/экспорта
Искажение данных при нецентрализованном хранении.
Варианты распределенного доступа к данным (Сервер БД/Файловый сервер).
Выбор ориентированных на разные задачи различных систем от разных поставщиков
(а это, к сожалению, неизбежно) влечет за собой проблему хранения одних и тех
же данных, записываемых/читаемых разными приложениями. Приложения могут воспринимать
одни и те же данные в разных форматах, структурируя эти данные по-разному; приложения
могут хранить одни и те же данные в файлах данных или в базах данных локально
или централизованно, мало того, отдельные данные могут вообще вычисляться в
одном приложении, а в другом сохраняться в чистом виде. Такая путаница,
если ее не разрулить, быстро и легко приводит либо к искажению данных, либо
к серьезным разночтениям по данным в разных приложениях, не говоря уже об ошибках,
возникающих при прямом импорте/экспорте.
Единственное решение этой проблемы централизация данных в одном месте, в файловом
хранилище (Vault Server), управляемом сервером баз данных (например, Oracle
Server). Для этого необходимо разработать концепцию единой сетевой инфраструктуры
предприятия, чтобы обеспечить переход от островковой автоматизации к комплексной.
Также немаловажно определить тип данных (об этом было рассказано выше) по ролевому
признаку и назначить права доступа к данным групп пользователей. При этом атрибуты
данных, хранимых на сервере, являются атомарными (неделимыми), тогда как атрибуты
данных, отображаемые приложением для пользователя, могут являться композициями
атрибутов хранимых данных (например, если в приложении необходимо указать размерные
величины в дюймах, то с сервера забираются размеры в миллиметрах, и с сервера
же забираются коэффициент и формула пересчета). Этим достаточно легко решаются
проблемы представления и импорта/экспорта данных.
Сложнее обстоит дело с базами данных, управляемыми различными СУБД. Существуют
два известных решения: синхронизация или шлюзование баз данных. Однако первый
вариант приводит к децентрализации данных, и поэтому мы выбрали шлюзование.
6. Сетевая политика. Новые правила работы в потоке работ
Дисциплина пользователя, подчиняющаяся логике его функций (бизнес-процесс).
Разграничение полномочий. Распределенная работа с общими данными.
Вкратце и частично о сетевой политике (а именно о правах доступа) было рассказано
выше в некоторых разделах. Там же было рассказано о ролевой дифференциации данных.
Остается дифференцировать по ролевому признаку пользователей.
Рассмотрим такую дифференциацию на примере работы конструктора и технолога.
Для этого необходимо логически описать процессы, в которых они участвуют (бизнес-процессы).
Возьмем два основных процесса: Разработка и Согласование. У них имеются
следующие типы участников: инициаторы, исполнители и аудиторы, при этом на различных
этапах этих процессов различные роли могут исполнять как конструкторы, так и
технологи. Роль подразумевает определенный набор правил, которым должен следовать
участник. Сюда же входят права доступа к объектам (писатель, читатель и др.)
и права доступа к процессам (в зависимости от статуса).
Если бизнес-процесс описан корректно и логически целостно, и все участники процесса
принимают и соблюдают его правила, то сформировать на основе этого бизнес-процесса
сетевую политику несложно.
Все участники процесса манипулируют данными, при этом доступ к данным может
быть разрешен одновременно как только одному, так и многим пользователям (совместная
работа). Распределенный доступ к данным подразумевает некие правила, способ
построения которых только что был описан.
В этом разделе мы сознательно не описывали методики обеспечения безопасности
сети. Они широко известны.
7. Ожидаемая интеллектуальность как результат
Автоматизация рутинных и тривиальных операций.
Гуманизация машинного интерфейса.
Никто, вероятно, не возьмется оспаривать то, что талант невозможно формализовать.
Однако разделим ремесло и искусство. Уискусства есть общеизвестные законы,
и здесь все зависит от таланта, тогда как у ремесла законы тщательно скрываются
их носителями и передаются приватно. Раскрыв эти законы, мы сумеем формализовать
формализуемое. Вопрос неформализуемого (таланта) остается за человеком. Но даже
это пользователь сможет пощупать, пользуясь инструментами и методами, о которых
мы говорили выше.
Ответим на последний вопрос: чего же ждет от нас пользователь? Простоты, удобства
и понятности. А это задача команды ИТ-менеджеров, работающей в тесном контакте
с пользователями (обратная связь).
И, в качестве резюме:
Конструктор, работающий на кульмане, имеет за плечами 56 лет обучения в вузе,
и опыт, приобретенный за все время рабочего стажа. Соблюдая правила, принятые
при коллективной работе в сети с информационными технологиями, и тщательно изучив
азы такой работы (это где-то два месяца обучения непосредственно на рабочем
месте), конструктор сможет максимально эффективно использовать программный инструмент,
пользуясь не только всеми своими знаниями и опытом, полученными ранее, а также
и обобщенным опытом и знаниями всех пользователей корпоративной системы.
КОМПЬЮТЕР-ИНФОРМ
Рубрики || Работа
|| Услуги || Поиск
|| Архив || Дни
рождения
О "КИ" || График
выхода || Карта сайта || Подписка
Рассылка анонсов газеты по электронной почте
Сайт газеты "Компьютер-Информ" является зарегистрированным электронным СМИ.
Свидетельство Эл 77-4461 от 2 апреля 2001 г.
Перепечатка материалов
без письменного согласия редакции запрещена.
При использовании материалов газеты в Интернет гиперссылка обязательна.
Телефон редакции (812) 718-6666, 718-6555.
Адрес: 196084, СПб, ул.Заставская, д.23, БЦ "Авиатор", 3-й этаж, офис 307
e-mail: editor@ci.ru
Для пресс-релизов и новостей news@ci.ru