CADmaster

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

Недавно перечитали статью о нетиповых решениях на базе TechnologiCS ¹. Не вдаваясь в подробности, кратко сформулируем основное ее содержание: гибкость инструмента (в данном случае TechnologiCS), а также знания и опыт консультантов позволяют реализовать практически «именное» решение, очень точно соответствующее индивидуальным требованиям предприятия. Хороший результат для определенного уровня развития. Однако представьте себе ситуацию, когда таких «именных» систем становится много, а значит и объем специально разработанных для них программных расширений, структур и способов ведения данных также становится очень большим. Хорошо, если в процессе внедрения удается создать на предприятии центр компетенции, состоящий из специалистов, способных снять все вопросы по сопровождению и развитию системы. Но практика показала, что это достаточно дорогое удовольствие. В общем случае специалисты предприятия должны выполнять функции первой линии техподдержки, то есть реагировать на возникающие проблемы и правильно их классифицировать, самостоятельно устраняя те, которые связаны с ошибками в действиях пользователей. Проблемы, связанные с поломками либо ошибками в программном обеспечении, должны ретранслироваться во вторую линию, то есть к авторам решения, либо далее, к разработчикам.

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

Но вплотную заняться типизацией заставила задача, поставленная перед нами одним из ключевых заказчиков…

Типовое решение — история вопроса

ТВЭЛ — топливная компания Росатома, объединяющая ряд предприятий по производству ядерного топлива, поставила целью внедрить автоматизированную систему подготовки производства (АСУ КТПП). Внедрить не на пустом месте и не «с нуля». На одном из предприятий компании — Новосибирском заводе химических концентратов (НЗХК) — нами уже была внедрена и в течение ряда лет успешно эксплуатировалась АСУ КТПП на базе программного обеспечения Technologies ².

Работающая АСУ КТПП рассматривалась при этом как прототип, на базе которого необходимо разработать типовое решение и впоследствии тиражировать его на остальные предприятия. Подобная постановка задачи была продиктована необходимостью минимизировать затраты как на проектирование и реализацию, так и на дальнейшее сопровождение и развитие АСУ КТПП. Когда в целом все понятно, остается разобраться с деталями. И тут начали возникать проблемы, главная из которых состояла в том, что ни заказчик (ТВЭЛ), ни предполагаемый исполнитель (CSoft) не могли четко сформулировать, что должно собой представлять типовое решение, из каких компонентов оно должно состоять и чем оно будет отличаться от обычных решений.

Чтобы с чего-то начать, была предложена достаточно общая декларация целей создания типового решения:

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

Но чем дальше мы пытались продвинуться от деклараций к делу, тем больше всех волновал вопрос:

Типовое решение — возможно ли оно в принципе?

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

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

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

Для всех участников проекта по созданию типового решения была очевидной невозможность переноса решения НЗХК на другие предприятия без изменений, под копирку.

Для того чтобы понять, что можно типизировать, мы сначала отсекли категории, которые однозначно не подлежат типизации: организационную структуру предприятия, виды и состав конструкторской и технологической документации и пр. Нам могут возразить — организационная структура должна оптимизироваться, состав документации определяется требованиями ЕСКД и ЕСТД. Всё так, только не для нашего случая, так как одно предприятие работает исключительно с использованием конструкторской документации стороннего разработчика, а другое разрабатывает собственную документацию. Отсюда объективные различия и в организационной структуре, и в составе документации.

Следующим шагом стало обращение к опыту процессных внедрений (к тому же проекту по созданию АСУ КТПП НЗХК) и выдвижение гипотезы о том, что процессы как объекты автоматизации носят объективный характер и даже при внешней непохожести могут иметь существенную типовую составляющую. Более того, суть процессов практически не зависит ни от организационной структуры, ни от состава документации.

Если гипотеза подтвердится, то задача типизации приобретет реальные очертания и в результате ее решения мы сможем получить:

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

Гипотезы, как известно, проверяются экспериментом. При этом требования к эксперименту довольно очевидны:

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

Эти требования призваны максимально защитить результат эксперимента от влияния человеческого фактора. Надо отметить, что планирование и постановка эксперимента позволили получить самостоятельный результат, который мы назвали

Методика разработки типового решения

1. Исходные данные

Модели процессов «Как будет», выполненные в разное время разными исполнителями для разных предприятий. Эти модели мы действительно не собирались подвергать каким-то экспериментам, так как к моменту окончания их разработки были еще далеки от понимания того, что и каким образом мы будем типизировать.

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

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

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

2. Представление бизнес-сценариев

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

• основной процесс организации КТПП;
• конструкторская подготовка производства;
• технологическая подготовка производства;
• управление работами;
• управление документацией.

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

Рис. 1. Диаграмма сценариев

3. Анализ процессов, выделение типовых составляющих и синтез типовых моделей

Как уже упоминалось, анализ должен быть формальным. Для того чтобы это было возможно, необходимо привести процессы к «общему знаменателю». На первый взгляд, сделать это крайне затруднительно. Достаточно посмотреть на фрагменты процессов разных предприятий, расположенные в одной строке диаграммы сценариев (и, следовательно, имеющие типовую часть) и приведенные на рис. 2 и 3.

Рис. 2. Фрагмент процесса разработки технологического процесса НЗХК

Рис. 3. Фрагмент процесса разработки технологического процесса ЧМЗ

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

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

Выполнив скрипт в базе данных ARIS, мы получаем таблицу, фрагмент которой приведен на рис. 4.

Рис. 4. Фрагмент результата обработки процессов

Таблица содержит разделы, соответствующие сравниваемым процессам разных предприятий (в данном случае НЗХК и ЧМЗ), а также раздел, соответствующий типовому решению (ТР). Необходимо обратить внимание, что сравнивать можно процессы, которые располагаются в одной строке диаграммы сценариев (например, процесс «Разработка документа ТД» НЗХК и «Разработка нового ТП» ЧМЗ). Другими словами, вначале мы на диаграмме сценариев сопоставили процессы, после чего для сопоставленных процессов выполнили ту же процедуру для их содержимого — функций и ролей. По горизонтали в таблице расположены функции, встречающиеся в процессах, а по вертикали — бизнес-роли. Пересечения показывают использование функций в процессах.

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

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

Рис. 5. Фрагмент типового процесса

Отметим еще один результат эксперимента — кроме типовой части, мы получили индивидуальные составляющие решения для каждого предприятия. Таким образом, структура типового решения стала выглядеть так, как это показано на рис. 6.

Рис. 6. Структура типового решения

Структура типового решения позволяет провести аналогию с групповым изделием, имеющим постоянную и переменную части. Преимущества подобного представления очевидны:

• на каждое новое предприятие мы приходим по крайней мере с готовой типовой частью решения, которая впоследствии адаптируется под новые условия;
• мы вместе с заказчиком экономим время и ресурсы на внедрении, за счет существенного сокращения сроков проектирования. По сути, каждый раз проектируется только переменная часть;
• мы вместе с заказчиком экономим время и ресурсы на сопровождение и развитие системы. Если каждая АСУ КТПП представляет собой множество процессов, данных и методов, то типовое решение — это пересечение этих множеств. Объединение множеств — это тот самый объем, который надо сопровождать и развивать. Понятно, что он меньше арифметической суммы всех элементов АСУ КТПП при индивидуальном подходе ровно на объем типового решения.

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

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

Об этих составляющих типового решения мы обязательно расскажем в одной из следующих статей.

Скачать статью в формате PDF — 1.27 Мбайт