TechnologiCS 6 — процессный подход к разработке и внедрению
Трудности внедрения
Наряду со всеми преимуществами комплексного внедрения систем технической подготовки и управления производством всегда существует и ряд объективных трудностей, возникающих при адаптации решений подобного рода. Под объективными трудностями будем понимать такие, которые не зависят от специфики конкретного предприятия или вида и объема внедряемого решения. Такие трудности возникают и у разработчика программного обеспечения, и у промышленных предприятий, которые приступают к комплексному решению своих проблем, опираясь, как правило, только на собственный опыт.
Основными трудностями при внедрении комплексных решений для промышленных предприятий являются как большая номенклатура используемых программных средств, связанная с недостаточной функциональностью какого-то одного выбранного продукта или продуктов одной компании-производителя, так и существенно устаревшая нормативная база для решения задач технической подготовки и управления производством, ориентированная на бумажный документооборот.
Разработчика программных средств объективные трудности приводят:
- к необходимости постоянно наращивать функциональность своих продуктов;
- к проблемам с использованием имеющейся функциональности, поскольку на предприятиях, как правило, уже работают решения с похожей функциональностью, но от других производителей — в том числе продукты, разработанные самим предприятием, обычно ориентированные на его специфику.
Объективные трудности внедрения зарубежных продуктов помимо этого связаны не только с адаптацией программных средств к специфике отечественных стандартов, но и с существенными различиями в подходах к подготовке и методах управления производством.
Поэтому если на предприятии полностью отсутствуют программные средства (отметим, что такого практически не бывает) или функциональность имеющихся средств полностью перекрывается системой TechnologiCS (например, задачи конструкторско-технологической подготовки производства (КТПП) — см. рис. 1), то, как правило, проблем не возникает и внедрение представляет собой создание новых или конвертацию имеющихся баз данных, а также настройку системы на специфику предприятия.
Совсем другая картина складывается там, где имеющиеся программные средства выходят за рамки функциональности TechnologiCS или попутно с основными решают какие-то специфические задачи, учитывающие особенности конкретного предприятия (например, PDM и ERP — см. рис. 1). Здесь внедрение сталкивается с существенными трудностями, связанными с кропотливой разработкой разного рода регламентов, программных интерфейсов или специальных структур для конвертации и передачи данных из внешних систем и обратно.
Рис. 1. Трудности решения задач автоматизации
Рис. 2. Взаимодействие процессов, требующих автоматизации
Преодоление этих объективных трудностей видится в создании информационных систем, использующих процессный подход и позволяющих как развивать собственные решения, так и использовать решения других производителей программного обеспечения.
Сегодня большинство представленных на рынке систем построено по структурному принципу, то есть имеет заложенные при проектировании свои структуры данных, API для работы с ними и интерфейс пользователя, предназначенный для реализации базовой функциональности системы. Разработчики, занимающиеся проблемами интеграции подобных программных средств, идут, как правило, тремя основными путями:
- используют при построении собственной системы разного рода стандарты для обмена данными между программными средствами, такие как ODMA, группа стандартов STEP (ISO 10303), IGES и т.д.;
- создают программный интерфейс (API), специализированный для решения конкретного круга задач и обеспечивающий функциональность собственной системы;
- разрабатывают специальные структуры данных для обмена между собственными программными средствами, а также конверторы для передачи данных из внешних систем и обратно.
Каждый из этих путей имеет и преимущества, и определенные недостатки. Однако отметим, что для систем, построенных на основе структурного подхода, эти пути являются практически единственными, а самое главное — при их реализации обязательно участие разработчика.
Современные тенденции развития программных средств показывают, что одним из лучших здесь является процессный подход, когда задачи автоматизации формализуются в виде процессов, представляющих собой, как сказано в стандартах на системы менеджмента качества ISO 9000:2000 (п. 3.4.1), «совокупность взаимосвязанных или взаимодействующих видов деятельности, которые преобразуют входы в выходы». Там же дается пояснение, что «любая деятельность или совокупность видов деятельности, которая использует ресурсы для преобразования входов в выходы, может рассматриваться как процесс». Других определений процесса, закрепленных на международном или государственном уровне, пока, к сожалению, не существует. Будем также понимать, что процессы состоят из процедур, представляющих собой повторяющиеся последовательности действий, приводящих к определенному результату.
Таким образом, основные задачи автоматизации можно представить в виде набора «кубиков» (процессов), у которых информационные входы одних связаны с информационными выходами других (рис. 2).
Например, систему ERP обычно представляют набором, состоящим из следующих процессов:
- Sales and Operation Planning (SOP) — планирование продаж и операций;
- Master Production Scheduling (MPS) — объемно-календарное планирование;
- Inventory Transaction Subsystem (ITS) — управление движением запасов;
- Scheduled Receipts Subsystem (SRS) — управление плановыми поставками;
- Material Requirement Planning (MRP) — планирование потребности в материалах;
- Bill of Materials (BOM) — ведомость основных материалов;
- Capacity Requirement Planning (CRP) — планирование потребности в мощностях и т.д.
В условиях, когда заказчик свои процессы уже разработал, утвердил и запустил в промышленную эксплуатацию, система, спроектированная с учетом процессного подхода, должна обеспечивать гибкую настройку на входы и выходы имеющихся процессов, которые она либо не покрывает функционально, либо по каким-то причинам принято решение поддерживать ряд процессов уже имеющимся на предприятии программным обеспечением (рис. 3).
Рис. 3. Процессный подход к автоматизации
Процессный подход к разработке
Любая программная система имеет собственные структуры данных. Естественно, эти структуры организованы так, чтобы обеспечить эффективную работу базового функционала системы и, в свою очередь, оптимизированы под имеющийся в системе набор базовых интерфейсов пользователя.
Во время внедрения необходима поддержка процессов, функциональность и объем которых, как правило, заранее неизвестны, и зачастую возникает ситуация, когда для автоматизации процесса необходима обработка данных, не заложенная разработчиком в базовую функциональность системы. Построение системы, выполняющей запросы и обработку данных в обход заложенной разработчиком структуры, всегда будет стоить очень дорого с точки зрения как машинных ресурсов, так и трудоемкости разработки дополнительного программного кода.
Пожалуй, единственный выход из этой ситуации — предоставить пользователю открытый механизм для построения собственных структур данных. Причем в целях обеспечения целостности данных и реализации прав доступа это должен быть не механизм прямого доступа к таблицам SQL-сервера, а механизм доступа к данным с помощью самих объектов системы. В TechnologiCS 6 такой механизм называется Наборы данных (рис. 4) и реализуется с помощью специального инструмента Визуальный построитель запросов (рис. 5).
Рис. 4. Справочник наборов данных TechnologiCS 6
Рис. 5. Визуальный построитель запросов TechnologiCS 6
Визуальный построитель запросов предназначен для построения пользователем запросов к объектам TechnologiCS в удобном и понятном виде, как это принято в большинстве информационных систем. Окно построителя запросов состоит из следующих областей:
- Рабочая область — область, где отображены таблицы и связи между ними;
- Область таблиц — здесь расположен список таблиц, доступных для выбора;
- Область редактирования — область, позволяющая изменять набор данных и содержащая следующие закладки:
- Таблицы — содержит список рабочих таблиц,
- Поля — содержит список выбранных для запроса полей,
- Связи — содержит список созданных связей между таблицами,
- Фильтр — настройки фильтра,
- Сортировка — настройки порядка сортировки,
- Расч. поля — позволяет использовать расчетные и агрегирующие функции в построителе запросов,
- Макрос — макрос, который будет использоваться для получения значений расчетных полей,
- Группировка — группировка полей для использования агрегирующих функций в расчетных полях,
- Параметры запроса — содержит список параметров набора данных,
- П- одзапросы — содержит список используемых подзапросов (наборов данных) и условия связи,
- SQL — содержит текст SQL-запроса,
- Результаты — отображает результат запроса в виде таблицы.
Конечно, SQL-запрос виртуален и состоит из объектов TechnologiCS. Тем не менее пользователь всегда может создавать собственные наборы данных и использовать их в визуальных формах, скриптах, отчетах и т.д., расширяя тем самым базовую функциональность системы.
Наряду с собственными структурами данных любая программная система содержит также набор окон и встроенных алгоритмов обработки данных, которые вместе образуют интерфейс пользователя. Естественно, этот интерфейс является для системы базовым и оптимизирован для работы со встроенными в систему структурами данных. Как правило, степень детализации процессов в таком интерфейсе максимальная, да и встроенные функции сгруппированы не всегда так, как это требуется конечному пользователю. Отсюда и возникают трудности, связанные с чрезмерно перегруженным интерфейсом и необходимостью открывать большое количество окон для реализации, казалось бы, самых простых функций.
Для преодоления таких трудностей в TechnologiCS 6 разработан специальный механизм, позволяющий пользователю создавать для работы собственные экранные формы, задавая им с помощью TechnologiCS API собственные алгоритмы обработки данных. Этот механизм называется Редактором форм и состоит из Редактора кода (рис. 6) и Дизайнера форм (рис. 7).
Рис. 6. Редактор кода TechnologiCS 6
Рис. 7. Дизайнер форм TechnologiCS 6
Редактор кода представляет собой среду разработки, предназначенную для создания и редактирования макросов на языке VBScript, и является полнофункциональным редактором текста. При работе с редактором доступны операции с блоками текста, функции поиска и замены, цветовое выделение синтаксических элементов программных модулей и т.д.
Дизайнер форм, в свою очередь, предназначен для визуального проектирования элементов формы. Таким образом, пользователь может не только самостоятельно разрабатывать собственные структуры данных, но и создавать свои формы для ввода и отображения информации.
Для модификации стандартного и создания собственного интерфейса пользователя существует механизм, называемый Дизайнером интерфейсов (рис. 8).
Этот механизм позволяет сделать систему более гибкой, предоставляя пользователю возможность настраивать конкретные рабочие места, значительно упрощать интерфейс, заданный разработчиком, создавать свои кнопки, экранные формы и макросы.
Рис. 8. Дизайнер интерфейсов TechnologiCS 6
Рис. 9. Построение интерфейсов пользователя «как требуется»
Таким образом, пользователь может самостоятельно разрабатывать и поддерживать собственные процессы, формируя автоматизированные рабочие места различной функциональности и, что очень важно, не прибегая при этом к услугам разработчика.
Процессный подход к внедрению
Учитывая имеющуюся функциональность, в процессе внедрения TechnologiCS 6 стал возможен охват более широкого круга задач и выход на качественно новый уровень интеграции с внешними системами.
Во-первых, появилась возможность гибко встраивать систему в имеющуюся на предприятии информационную среду, выполняя последовательно несколько основных шагов:
- создать описания процессов «как есть». Этот пункт, как правило, является отправной точкой любого внедрения. Здесь очень важно тщательно разграничить функциональные рамки процессов, а самое главное — определить наборы входной и выходной информации для каждого процесса;
- провести реинжиниринг процессов с указанием того, «как нужно», если в этом есть необходимость;
- разработать структуры данных для обеспечения информацией входов и выходов процессов;
- создать структуры с помощью API и инструментов Наборы данных и Визуальный построитель запросов.
Во-вторых, обеспечить пользователю возможность вводить и обрабатывать данные так, как ему нужно, даже если такая обработка не входит в базовую функциональность системы. Для этого необходимо:
- разработать и детально описать процедуры, входящие в автоматизируемые процессы;
- с помощью Визуального построителя запросов, API и Редактора форм создать обработчики и экранные формы «как требуется» (рис. 9);
- создать собственные АРМы, поддерживающие разработанные процедуры путем трансформации базовых интерфейсов и/или разработки новых с помощью API и Дизайнера интерфейсов.
Неоспоримые преимущества
Представленный подход к разработке и внедрению дает системе, спроектированной в рамках процессного подхода, неоспоримые преимущества по отношению к имеющимся на рынке системам, построенным по структурному принципу.
Пользователь может разрабатывать собственные структуры данных, отсутствующие в системе.
Поскольку эти структуры основаны не на таблицах базы данных, а на объектах системы, они будут поддерживаться и в будущем, как бы разработчик ни трансформировал внутреннюю структуру данных.
Разрабатывая собственные структуры, пользователь, тем не менее, остается в рамках единой базы данных, а следовательно, система поддерживает и в будущем всегда будет автоматически поддерживать целостность его данных.
Помимо обеспечения целостности пользовательских данных, система автоматически разграничивает права доступа к ним в соответствии с общей настройкой системы.
Пользователь может разрабатывать неограниченное количество АРМов требуемой функциональности, оставаясь в рамках единой базы данных и используя необходимые ему функции базового интерфейса.
В будущем, в случае изменения состава процедур или объема автоматизируемых процессов, пользователь всегда сможет адаптировать свои структуры данных и разработанные им интерфейсы, не прибегая к услугам разработчика.
Проходит время, и все мы видим, как исчезают порой даже крупные компании и на их место приходят новые разработчики — интеграторы решений. Но независимо от этого системы, спроектированные в рамках процессного подхода, обеспечивают и всегда будут обеспечивать пользователю возможность самостоятельной поддержки, развития, а следовательно, и существенного повышения устойчивости бизнеса.
