CALS: трудное возвращение к эффективному сотрудничеству

Стратегия непрерывного сбора данных о производимых изделиях и поддержки жизненного цикла (CALS) существенно ускоряет интеграцию машиностроительных и ИТ-компаний.

В одной красивой притче рассказывается о том, как Господь показал приверженцу своего учения ад и рай. В зале, уставленном столами со всевозможными яствами, сидели голодные, изможденные люди, однако есть они не могли: пораженные локтевые суставы не давали им поднести пищу ко рту. В другом зале была такая же обстановка и такие же искалеченные люди. Но... они кормили друг друга.

Сегодняшний успех в бизнесе следует рассматривать лишь как преимущество на определенный, довольно ограниченный срок, позволяющий подготовиться к новым экономическим баталиям. Это хорошо понимают за рубежом: в поисках новых резервов и взаимовыгодного сотрудничества компании ведут процессы консолидации по разным отраслевым направлениям, перешагивая не только корпоративные, но и национальные границы. Свою лепту в эти процессы вносит стратегия CALS (Continuous Acquisition and Life-Cycle Support), которая существенно ускоряет интеграцию машиностроительных и ИТ-компаний, помогая им отстаивать и расширять границы своего «рая».

Эти процессы, к сожалению, все еще не затрагивают отечественных машиностроителей и отечественный ИТ-бизнес. Между тем зарубежные производители активно вытесняют отечественных: машиностроители теряют зарубежный и российский рынки наукоемкой продукции, а ИТ-бизнес — и без того скромный рынок корпоративных информационных систем.

Цель настоящей статьи — показав, насколько нужны CALS-технологии сегодня и как глубоко взаимозависимы в их реализации отечественное машиностроение и ИТ-бизнес, подтолкнуть их к грамотному и эффективному сотрудничеству.

Специфика CALS

Реинжиниринг бизнес-процессов. Стратегия CALS кардинально отличается от других бизнес-стратегий. С точки зрения управления — тем, что требует централизации управления, увязки и гармонизации методологий проектирования/производства участников совместных проектов, корпоративных культур, а в многонациональных проектах — и национальных культур. С точки зрения ведения бизнеса — тем, что организует большинство работ основной деятельности через «виртуальное изделие», электронное описание изделия (ЭОИ). С точки зрения ИТ — тем, что образует единое информационное пространство и позволяет перейти от лоскутной автоматизации и точечной интеграции приложений к автоматизированной системе управления созданием и использованием ЭОИ.

Формализация информационного взаимодействия. Многократно возросшая интенсификация труда, сложность целевых проектов, к которой теперь добавилось создание изделия через его виртуальное описание, требует активного использования формализованных методов представления и обработки данных управления целевыми и CALS-проектами.

Переход на формальные методы обработки информации, как правило, влечет за собой изменение стиля делового общения и культуры труда. CALS, особенно в совместных проектах, предполагает жесткую формализацию информационных взаимоотношений не только на уровне управления, но и на уровне взаимодействия исполнителей. Как бы мы ни привыкли к «нормальному» человеческому общению, каким бы ни был наш менталитет, необходимо прививать новую культуру общения. В настоящее же время на предприятиях не научились даже эффективно использовать электронную почту.

Системные мультипрограммные решения вместо «эта система лучше всех». Стратегия CALS заведомо исходит из того, что один программный продукт, пусть и «самый-самый» не сможет удовлетворить основные потребности предприятия. Практика доказывает, что такое трудно достижимо даже в рамках отдельно взятого предприятия, и уж тем более недостижимо при интеграции с информационными системами других предприятий. Именно поэтому главная сила CALS — в грамотных системных решениях и технологиях, а не в ставках на тот или иной программный продукт.

Оптимизирующая интеграция прикладных систем. Интеграция приложений сегодня стала одним из наиболее распространенных объектов спекуляций вокруг CALS. Этому способствует и многолетний культ лоскутной автоматизации в России, практикуемый и Заказчиком, и Подрядчиком.

Идеология лоскутного построения предельно проста: слона надо есть по частям. Реализуется эта идеология в виде следующей «технологии» создания информационных систем: обследовать, купить программный продукт (или на скорую руку, без серьезной проектной проработки создать), обучить персонал, внедрить. Дальше начинается точечная интеграция. Системы интегрируются «один к одному», регламент обмена информацией осуществляется на уровне примитивных планировщиков или вручную. Современные инструменты интеграции предлагают использование некоей «общей шины» для прикладных коммуникаций. Это, конечно, систематизирует технологию интеграции, но не меняет сути лоскутной автоматизации.

CALS требует принципиально иной, оптимизирующей технологии интеграции, которая предполагает не только интеграцию прикладных комплексов в единое целое, но и оптимизацию процессов информационного взаимодействия участников CALS-системы и их перепроектирование в соответствии с бизнес-технологиями и собственными средствами хранения и обработки данных. Примером такой задачи является управление конфигурацией изделий, конфигурацией технической документации и конфигурацией технических данных, которые при управлении ЭОИ очень взаимосвязаны и требуют тщательно продуманных проектных организационных, управленческих и технологических решений.

Интеграция приложений от разных поставщиков, да еще и в неоднородной технологической среде, никогда не была приятным занятием. Поставщики инструментов интеграции умалчивают, что эти средства есть не что иное, как средства транспортного и сеансового уровней, а не прикладные протоколы обмена. Разрабатывать прикладные протоколы Заказчику приходилось, приходится и придется впредь самостоятельно или с небольшим участием Подрядчика.

Ноу-хау и безопасность. В условиях совместной разработки изделия ее участникам нужна та или иная система правил, регулирующих аспекты интеллектуальной собственности.

CALS-система должна обеспечивать реализацию этих правил в мультипрограммной среде, чем она существенно отличается от большинства систем категорий MRP, ERP, CRM и т. д. При совместной работе совладельцев интеллектуальной собственности с множеством объектов ноу-хау приходится применять оригинальные режимы и протоколы доступа к этим объектам, что может не только повлиять на комплекс средств защиты, но и существенно изменить архитектуру информационной системы.

Сохранение и управление знаниями. Возросшие темпы создания новых изделий при многократном усложнении средств проектирования и производства требуют применения формальных способов описания знаний для их сохранения и дальнейшей эволюции. Это одна из наиболее актуальных задач отечественного наукоемкого машиностроения, обусловленная не только сложностью бизнес-технологий, но и сменой поколений разработчиков новой техники. Например, основная масса инженеров в авиастроении подошла к возрасту 55-60 лет, и их уход для промышленности будет не менее тяжелым, чем утечка умов на Запад. Это особенно относится к предприятиям, разрабатывающим новые поколения авиационной и другой техники. Многие военные эксперты и сами авиастроители не случайно говорят о том, что без сохранения и развития соответствующих знаний Россия очень скоро может потерять статус авиационной сверхдержавы. И никакой энтузиазм и фанатичная преданность любимому делу потом уже не помогут. Стоит напомнить, что Германия, несмотря на свой великий авиационный гений, после поражения во Второй мировой войне так и не смогла стать мировой авиационной державой.

Что же касается роли CALS-системы, сами принципы ее работы в значительной степени опираются на строго формализованные знания о бизнесе и об информационной системе предприятия. Поэтому при правильной реализации CALS-система в состоянии решить значительную долю задач по сохранению и управлению знаниями в фоновом режиме.

Централизация управления: когда в товарищах согласье есть

Преимущества бизнес-стратегии CALS сказываются лишь при условии управленческой, организационной и технологической консолидации участников CALS-проектов. Важнейшей и наиболее критичной для России является управленческая консолидация. Выражается она в создании стратегии бизнеса, соответствующей требованиям и условиям рынка, а также соответствующей системы управления бизнесом, так как только она позволяет реализовать все стратегии, замыслы, проекты и решения. И именно она становится краеугольным камнем в бизнес-новациях.

Готовность к изменению модели управления бизнесом — отличительная черта зарубежного бизнеса. Проявляется эта готовность, в частности, в том, что большая часть субъектов экономически развитых стран уже перешла или переходит от функционально-ориентированного управления бизнесом к процессно-ориентированному.

CALS-проекты требуют еще большей готовности к совместному проектированию и совместному производству, поскольку создают новые прецеденты и стандарты корпоративного сотрудничества. И готовность эта выражается в централизации управления.

Централизация управления есть необходимое условие для осуществления любого совместного проекта. Именно она обеспечивает создание устойчивой к возмущениям системы управления совместной деятельностью нескольких коллективов. Она же требует высокой исполнительной дисциплины, при которой каждый участник обязан следовать установленной системе правил. К сожалению, популистские мифы о «демократических» методах децентрализованного управления, модные в России и сейчас, мешают эффективному управлению не только на уровне совместных проектов, но даже на уровне предприятий. В совместно проводимых проектах децентрализованного управления быть не может. Правильнее было бы говорить о декомпозиции управления, о распределении функций управления. Но «семи нянек» у проекта быть не должно; отсутствие централизованного управления заведомо приводит к провалу проекта.

Поэтому прежде чем говорить о совместных проектах, отечественным производителям необходимо решить вопрос о централизованном управлении, четко определив, чем будет реально обеспечен его исполнительный механизм.

Уверены ли вы, что это CALS?

К CALS-технологиям сегодня относят едва ли не все, что одновременно связано с выполнением проектных, производственных и логистических функций или хоть как-то связано с интеграцией данных об изделии и соответствующего программного обеспечения. Различные источники дают разные определения CALS — от «протокола цифровой передачи данных...» [4] до «стека информационных технологий, помещающего все ссылочные данные о продукте в одно место» [5].

Подобная неразбериха развязывает руки многим производителям программных продуктов и консалтинговым фирмам, которые под флагом CALS навязывают Заказчику различные прикладные программные продукты и средства интеграции. Неудивительно и то, что на этой почве то тут, то там появляются отчеты и статьи об «успехах в создании автоматизированных систем на принципах CALS».

Между тем еще в 1997 году В. И. Дмитров в [6] отмечал, что ни одну из областей CALS нельзя рассматривать в отрыве от других: «Именно это не позволяет относить к CALS: просто набор международных стандартов; стандартный набор правил организации деятельности предприятий; стандартный набор программно-технических инструментов для интеграции предприятий; компьютеризированную систему создания технической документации; электронный обмен данными».

То же самое относится и к CALS-технологиям: все они теснейшим образом связаны друг с другом и выполняют свою миссию только вместе. Так что же относится и что не относится к CALS-технологиям?

К CALS-технологиями НЕ ОТНОСЯТСЯ (приведенный список может быть существенно расширен и лишь призван показать принципы, по которым автор отделяет CALS-технологии от других):

• технологии моделирования бизнес-процессов;
• технологии разметки данных;
• технологии документооборота;
• технологии управления потоками работ;
• технологии управления изменениями;
• технологии подготовки данных, поставляемые производителями частных прикладных систем вместе с этими системами (например, PDM, CAD/CAM/CAE и т. д.).

Первые пять пунктов являются общими для множества различных систем и носят самостоятельный, системный характер. Технологии подготовки данных отражают реализацию прикладных задач исключительно в рамках того программно-технического комплекса, для которого они созданы.

Теперь о том, что относится к CALS-технологиям. Это технологии, которые отражают специфику прикладных аспектов бизнеса Заказчика в многопрофильной среде (конструкторской, технологической, эксплуатационной и т. д.), и одновременно — специфику организации и обработки данных изделия в распределенной информационной системе с множеством прикладных программ. (Автор сознательно ограничивает область CALS теми технологиями, которые непосредственно составляют информационное окружение бизнеса Заказчика.)

Рассмотрим задачи CALS-технологий более пристально (содержание этих технологий и их взаимосвязь даны в [7]).

Формализованная технология описания бизнес-процессов на различных этапах жизненного цикла изделия. Призвана описать прикладные процессы и процессы информационного взаимодействия на уровне прикладных информационных объектов. Реализация этой технологии позволяет:

• разобраться в собственном бизнесе;
• обеспечить в дальнейшем автоматизированный контроль над бизнес-процессами;
• определить узкие места бизнес-технологий и решать задачи бизнес-реинжиниринга;
• определить концептуальные модели прикладных данных и функциональные требования к CALS-системе.

Формализованная технология сквозной обработки прикладных данных в информационной системе. Позволяет реализовать управление информационными процессами в CALS-системе на уровне ее исполнительных программно-технических механизмов. Это исключительно компьютерная технология, которая должна описать:

• форматы и стандарты представления данных ЭОИ;
• программно-технические средства и механизмы описания, подготовки, обработки, передачи и управления данными;
• интерфейсы и прикладные протоколы взаимодействия программных компонентов.

Эта технология позволяет ИТ-службе предприятия гарантированно управлять проектированием, созданием, модификацией распределенной программно-технической среды CALS-системы и осуществлять интеграцию ее компонентов.

Формализованная технология создания ЭОИ. Позволяет создать описание процессов создания виртуальных изделия, процессов, среды. Эта технология тесно связана с двумя предыдущими. ЭОИ является, с одной стороны, моделью реальных изделия, процессов и среды, а с другой — имеет собственную технологию создания и управления, основанную на ИТ-законах. Таким образом технология создания ЭОИ должна обеспечить хорошую стыковку с бизнес-технологиями проектирования изделий и в то же время обеспечить технические условия для создания и сопровождения устойчивой архитектуры ЭОИ, как можно меньше зависящей от изменений бизнес-технологий.

Формализованная технология автоматизированного информационного взаимодействия функциональных групп пользователей. Позволяет описать реализацию бизнес-процессов в заданной программно-технической среде с учетом специфики создания и использования ЭОИ, а также создать среду интегрированного информационного обеспечения, которая дает возможность предоставить пользователям необходимое для выполнения их функций информационное окружение.

Формализованная технология управления целевыми и CALS-проектами. Должна обеспечить участникам проектов: интегрированную среду доступа к календарным и оперативным планам; увязку планов управления с бизнес-процессами, объектами управления, исполнителями и ресурсами; интегрированную среду отслеживания состояния проектов, планов работ и обратную связь с ответственными исполнителями по всей вертикали и горизонтали оперативного управления.

Перечисленные формализованные технологии в совокупности позволяют:

• обеспечить требуемую степень контроля над бизнес-технологиями и используемыми в них ИТ;
• определить узкие места и решать задачи бизнес- и ИТ-реинжиниринга;
• определить технические требования к инфраструктуре и архитектуре CALS-системы, в том числе с учетом требуемых способов защиты данных и ноу-хау;
• определить недостатки существующей архитектуры прикладных данных и распределения функций между прикладными комплексами и разработать методику перехода от существующей информационной системы к оптимальной.

Их полная реализация в CALS-системе дает возможность:

• создать автоматизированную систему создания ЭОИ и ее производных (конструкторско-технологическая спецификация, рабоче-конструкторская документация, эксплуатационная документация и т. д.);
• создать интегрированную среду доступа к требуемой информации;
• создать систему хранения и использования знаний о бизнесе предприятия и его информационной среде;
• обеспечить непрерывное интегрированное информационное обеспечение пользователей требуемыми данными;
• гарантировать своевременное изменение бизнес-технологий и адекватное изменение программно-технического комплекса CALS-системы.

Два примера проектных решений. Электронный архив.

К сожалению, системный подход к созданию CALS-систем даже на уровне предприятий сегодня не практикуется. Все, что пытаются сделать предприятия — решить задачи создания отдельных программно-технических компонентов CALS-систем и кое-как вписать в существующую функциональную модель предприятия (причины такого положения описаны в [1, 2]). Одной из таких актуальных задач в машиностроении является создание электронных архивов технической документации и систем технического документооборота.

Подходить к ее решению можно по-разному: традиционно, создавая различные варианты локальных, лоскутных решений, или системно, комплексно, действительно используя принципы CALS-технологий.

Локальная система. На одном машиностроительном заводе при создании электронного архива были приняты следующие решения. Электронный архив полностью копирует функции и технологию работ с бумажным архивом. Управление хранилищем документов реализуется штатными средствами файловой системы Windows, а каталогизация и поиск документов — средствами офисных приложений Microsoft Office. Прямой доступ пользователей к электронному архиву запрещен в целях безопасности. Для того чтобы получить документ, пользователь отправляет запрос по электронной почте (Microsoft Exchange) оператору архива, который обрабатывает запрос, находит документ и отправляет его по электронной почте пользователю.

Не касаясь вопросов эффективности такого решения с точки зрения ИТ, отметим, что такая система проста, дешева, не требует специализированного программного обеспечения (а значит, и затрат на новые проектные и технологические решения, на внедрение, обучение пользователей, управление доступом и т. д.), обеспечивает требуемую степень безопасности. Существенным недостатком такого решения является изолированность электронного архива от остальной системы технического документооборота и невозможность создания на его базе системы с высокой производительностью и степенью автоматизации.

Оптимально интегрированная система. На другом предприятии электронный архив рассматривался как неотъемлемая часть системы технического документооборота. Здесь, кроме традиционных требований (функциональность, безопасность и т. д.) к системе управления хранилищем документов, были выставлены и специфические требования:

• Система должна быть единой для хранения не только архивной, но и всей документации предприятия, управляемой собственными разработками предприятия.
• Система должна обеспечить регистрацию, учет и управление съемными носителями в корпоративной информационной системе.
• Система должна обеспечить эффективную логическую сегментацию документации в соответствии со специфическими требованиями используемых на предприятии приложений.
• Система должна обеспечить оптимальную физическую сегментацию документации, гарантированно обеспечив эффективную миграцию документов и возможность управлять потоками документов в сети.

Прикладная часть электронного архива, которую следовало разработать специалистам предприятия на Oracle Developer, должна была использовать уже имеющиеся наработки предприятия в области технического документооборота. Наиболее проблемной являлась задача создания хранилища документов и его интеграции с прикладной частью архива.

Первый вариант построения хранилища документов основывался на концепции «единоначалия» PDM-системы в управлении техническими документами (на предприятии используется «тяжелая» система iMAN) и обладал такими важными преимуществами, как поддержка устройств хранения на платформах Windows и Unix, а также быстрая реализация хранилища за счет использования штатных средств управления хранением документов.

Второй вариант построения хранилища документов предполагал создание специализированного сервера управления хранилищем.

Руководством ИТ-службы было принято решение о создании обоих вариантов электронного архива. Оба варианта создавались силами предприятия.

Реализация первого варианта не обеспечила выполнения трех последних требований; более того, невозможность выполнения части требований была определена еще до начала реализации из-за ограничений архитектурной и программной реализации iMAN. Кроме того, потребовалось купить большое число дорогостоящих лицензий (для работы сотен рабочих мест) и модернизировать значительную часть ПК (реализация клиентской части, предполагавшая использование Java Run-Time и клиента iMAN, «съедала» 30-40 Мбайт оперативной памяти); сопровождение комплекса также было связано с существенными затратами.

Реализация второго варианта обеспечила выполнение всех требований. Лишенная недостатков, присущих первому варианту, система (минимальная стоимость, отсутствие необходимости в лицензиях, клиент «весом» 4 Мбайт) позволила существенно расширить функциональность. В частности, отделом вычислительной техники и телекоммуникаций был предложен вариант создания архивной системы для данных пользователей, хранящихся на «персоналках». Наиболее существенным недостатком второго варианта являлась поддержка только одной платформы — Windows.

Автору довелось быть техническим руководителем этого проекта; управление проектом было любопытно и с точки зрения аналогии с параллельной разработкой в машиностроении (хотя и в гораздо меньших масштабах). В создании архива принимали участие специалисты пяти отделов, при разработке программной части двух вариантов архива — трех ИТ-отделов. На создание программного комплекса электронного архива было отведено всего два с половиной месяца; первый вариант был выполнен в срок, второй — на месяц позже.

Существенным моментом была интеграция прикладной части с двумя разными программными реализациями хранилища (первая — на Java, вторая — на Delphi). Это определило выбор технологии реализации интерфейса и протокола обмена между подсистемами через СУБД Oracle. Работа над проектом велась классическим способом. Было подготовлено краткое технико-экономическое обоснование вариантов создания архива, подробное ТЗ, включившее функциональные требования, эксплуатационные требования, подробные требования к архитектуре системы, протоколам обмена, интерфейсам. Кроме этого в ТЗ была включена логическая модель данных хранилища, что позволило сильно ограничить «произвол» программистов в программной реализации и в итоге сократить время разработки.

Хорошо проработанные и согласованные требования к реализации системы позволили разработчикам всех трех отделов работать параллельно.

Единый SQL-ориентированный интерфейс и унифицированная модель данных позволяли создать одну реализацию прикладной части архива; к сожалению, разработчики первого варианта частично использовали собственные значения кодов запросов, отличные от кодов спецификации интерфейса, что привело к созданию двух реализаций прикладной части, хотя и с небольшими отличиями.

В целом проект показал, что взаимопонимание, следование системному подходу, хорошо продуманные проектные решения позволяют осуществлять быструю и эффективную параллельную работу нескольких команд.

Эпилог

В интервью корреспонденту «Коммерсанта» генеральный директор НПЦ «Технокомплекс» Гиви Джанджгава очень четко охарактеризовал сложившуюся в машиностроении ситуацию [8]: «Мы все, находясь на тонущем корабле, делим места: кто на второй, кто на третьей палубе. Но не важно, кто утонет минутой позже или минутой раньше, в итоге же не выкарабкается никто... Ведь внутри страны нет системообразующего заказа. Поэтому надо ?вываливаться? на внешний рынок. Но организованно, системно, с внедренной в отрасли международной системой качества. И не в одиночку, а соответствующими объединениями. Когда все друг от друга зависят, то никто не может выскочить из упряжки, никто не может цокнуть копытом: мол, ?я не буду, не хочу?. Не будет — помрет. Все идут в одной связке, как альпинисты».

Рынок машиностроительной продукции — огромный перспективный рынок не только для отечественного машиностроения. В его лице ИТ-бизнес, пусть и косвенно, тоже может «вывалиться» на внешний рынок. CALS-технологии дают обеим сторонам реальный шанс создать систему эффективного сотрудничества и поднять рынок высокотехнологичных продуктов на новую высоту. Хочется надеяться, что разум и чувство самосохранения возобладают над частными амбициями. Что и машиностроители, и ИТ-бизнес помогут друг другу выжить и не потерять рынок высоких технологий. Наш рынок.

Литература

Михаил Головко — независимый консультант по CALS-технологиям. С автором можно связаться по электронной почте по адресу MGolovko@yandex.ru