The Web-site of design Company Chelyabenergoproekt in English   English
Проектные работы в проектной организации Челябэнергопроект Заказать проектные работы в письме к проектной организации Челябэнергопроект Карта сайта
Die Web-seite der Projektorganisation Tscheljabenergoprojekt in Deutsch   Deutsch




Création de site web société française Chelyabenergoproekt   Française

   Облако тегов на сайте проектной организации Челябэнергопроект
Проекты интеллектуального мастерства!
новости компании
30.12.2015 С Новым годом!
Администрация ...
21.12.2015 С Днём Энергетика!
Уважаемые друзья и коллеги! Поздравляю вас с нашим большим праздником – Днем Энергетика! ...



новости отрасли
объекты Ростехнадзора
  Облако тегов
проектирование монтаж ключ котел кран сертификат ГОСТ ремонт заказЧелябинск

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

Рассмотрим некоторые способы построения информационных систем.

Рассмотрим процессный подход.

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

Процессно-ориентированная организация


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

Функционально-ориентированная организация


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

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

Рассмотрим функциональное и процессное внедрение ИС.

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

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

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

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

Говоря о процессном внедрении, нельзя не упомянуть об инструментарии, применяемом для моделирования бизнес-процессов. Сам по себе процессный подход не предъявляет особых требований к инструментам описания и проектирования бизнес-процессов, однако использование специализированных инструментов вместо стандартных офисных программ имеет массу неоспоримых преимуществ. Среди множества представленных на рынке инструментальных средств наиболее эффективным следует, пожалуй, признать программный продукт ARIS (этот вывод подтверждается результатами исследований, опубликованными Gartner Group в январе 2004 г.). ARIS (Architecture of integrated Information Systems – архитектура интегрированных информационных систем) представляет собой методологию и базирующееся на ней семейство программных продуктов, разработанных компанией IDS Scheer. Чтобы дать некоторое представление об ARIS, перечислим ее основные преимущества:
- представление бизнес-процессов в виде графических моделей;
- наличие единого стандарта моделирования;
- ориентация на процессный подход;
- наличие единого репозитория (базы данных), позволяющего использовать в разных диаграммах одни и те же объекты, совмещая различные точки зрения на организацию;
- возможность генерации разнообразных отчетов по разработанной модели – в том числе и отчетов, специально разработанных пользователем;
- возможность организации совместной работы в сетях Internet и Intranet.

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

Рассмотрим информационную систему и процессный подход.

Рассмотрим несколько типичных случаев автоматизации в проектной организации.

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

2. В проектной организации действует автоматизированная система управления (АСУП).
Наряду с прямым использованием бумажных документов (случай 1) часть из них вводится в систему для последующей обработки и получения сводной информации. Сводные данные (опять же в виде бумажных документов) используются службами-потребителями этой информации. При очевидных достоинствах такой способ имеет столь же очевидные недостатки. Достаточно сказать, что база данных проектной организации отделена документами от источника информации (конструктора, технолога) и ее потребителя (служб МТС, плановых, производственных подразделений). На ввод информации тратится определенное время – следовательно, снижается уровень актуальности данных, увеличивается вероятность ошибок как при вводе, так и при использовании данных.

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

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

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

Что же дает внедрение системы TechnologiCS в плане применения процессного подхода и совершенствования бизнес-процессов?

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

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


Перечислим основные преимущества рассматриваемого способа работы – с точки зрения организации процессов:
1. Реальная совместная работа с информацией в большинстве случаев позволяет перейти от последовательного способа обработки информации к параллельному. Другими словами, появляется возможность распараллелить бизнес-процесс, существенно сократить сроки разработки и сэкономить время для таких операций, как согласование, утверждение документации, внесение конструкторских и технологических изменений.
2. Работа в единой информационной среде делает процесс прозрачным и управляемым; каждый его участник видит и результат, и собственную роль в процессе. Подобная организация работы позволяет выстроить в рамках процесса цепочки взаимодействия функциональных подразделений и отдельных сотрудников.
3. При проектировании процессов с учетом использования информационной системы, как правило, выявляется ряд документов, полностью или частично дублирующих друг друга, а также документы, которые вообще могут быть выведены из употребления, поскольку содержащаяся в них информация может быть получена гораздо более эффективным способом.
4. Документ, получаемый в виде отчета из базы данных и сохраненный в архиве, становится частью информационной базы проектной организации и его интеллектуальной собственностью. Это снижает влияние человеческого фактора, а также риск искажения или утраты информации.

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

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

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

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

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

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

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

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

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

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

В рамках этой статьи мы ограничимся обзором первых двух этапов внедрения системы на Новосибирском заводе химконцентратов.

Рассмотрим этап подготовки проекта.

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

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

Рассмотрим концептуальное проектирование.

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

Далее выполняется проектирование бизнес-процессов «как должно быть».

Документ «План перехода к процессам как должно быть» – на рисунке.

Подготовка к процессному внедрению информационной системы


Основные функции TechnologiCS можно разделить на три группы:

I. Конструкторская подготовка:
- составление и ведение спецификаций;
- ведение дерева применяемости деталей и сборочных единиц;
- отслеживание полноты заполнения спецификаций проекта;
- ведение архива спецификаций (копирование, добавление, удаление);
- ведение библиотеки чертежей;
- получение сводных спецификаций на изделие любой сложности.

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

III. Расчеты:
- разузлование спецификаций;
- расчет потребности в материалах, специфицированной трудоемкости, себестоимости изделия, потребности в стандартных изделиях и комплектующих, циклограмм сборки;
- формирование карты сборки узла или изделия;
- получение сводных конструкторско-технологических документов;
- расчеты применяемости оборудования, материалов, номенклатуры цеха/участка.

Рассмотрим настройку TechnologiCS для реализации процессов конструкторско-технологической подготовки производства (КТПП).

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

Основные настройки, отвечающие за реализацию процессов электронного технического документооборота в системе TechnologiCS, располагаются в так называемых вспомогательных справочниках. Эти справочники, как правило, настраиваются единожды и в дальнейшем изменяются только при изменениях процессов в проектной организации:
1. «Виды документов» – содержит используемые в проектной организации виды электронных документов с их атрибутами, маршрутами проверки/согласования;
2. «Атрибуты» – содержит список возможных атрибутов для электронных документов;
3. «Типы файлов» – содержит типы используемых файлов с настройкой для каждого типа соответствующих ему команд и внешних приложений обработчиков;
4. «Способы обработки документов» – содержит шаблоны маршрутов, в соответствии с которыми происходит изменение статуса документа в процессе электронного документооборота;
5. «Статусы» – содержит все возможные статусы, которые может иметь документ в электронном архиве, с настройкой доступных действий над документом в каждом статусе;
6. «Виды связей документов» – содержит список возможных связей, которые могут устанавливаться между версиями документов;
7. «Виды подписей» – содержит список всевозможных видов подписей, которые могут быть проставлены на документе в процессе различных проверок и согласований;
8. «Рабочие группы» – содержит список рабочих групп. Рабочие группы объединяют пользователей с различными ролями при работе с одними и теми же документами. Выполняемая в рабочей группе роль определяет права доступа пользователя к данному документу, например, просмотр документа и простановка/отмена соответствующей подписи;
9. «Роли» – содержит список ролей с настроенными шаблонами прав;
10. «Шаблоны прав» – содержит список шаблонов прав с настроенными возможными действиями над документом;
11. «Справочные таблицы» – в зависимости от отдела разработчика, вида документа и объекта, к которому он относится, содержат сведения для автоматического размещения документа в электронном архиве (используются при создании документов с помощью соответствующих скриптов);
12. «Скриптовые модули» – содержит модули со специально разработанными скриптами. Такие скрипты, состоящие из последовательно вызываемых стандартных действий, по окончании работы обеспечивают создание необходимых взаимосвязанных записей в различных режимах системы, не позволяя пользователю забыть сделать все необходимое.

Рассмотрим управление информацией в электронном архиве TechnologiCS.

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

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

Рассмотрим разработку документов в электронном архиве TechnologiCS.

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

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

Помещение в электронный архив существующего документа и извещения, по которому внесено последнее изменение


Для всех новых документов, помещенных в электронный архив со своей первой версии (соответствующей подлиннику без изменений), для разработчиков необходимо написать скрипт «Создание документа РКД с нуля». При этом система автоматически создает и помещает в нужный раздел архива документ вида «Извещение 0». Обозначения для таких извещений генерируются системой автоматически. Затем создается технический документ, автоматически именуется его версия (в соответствии с оговоренным шаблоном), которая связывается с извещением. Оба документа связываются с деталью или сборочной единицей, к которой они относятся. Файл документа добавляется в версию основного документа или разрабатывается непосредственно в электронном архиве.

Связи между документами и объектами БД


Рассмотрим внесение изменений в документы в электронном архиве TechnologiCS.

При необходимости внесения в документы изменений используется скрипт «Создание ИИ РКД» (для изменения документов по извещению об изменении) или скрипт «Создание ПИ РКД» (для проведения предварительных изменений в документах).

Электронные документы, связанные со сборочной единицей, и возможные действия конструктора при работе с ними
Список документов, которые изменятся и аннулируются после утверждения и введения в действие извещения


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

Электронные документы, связанные со сборочной единицей, и возможные действия конструктора при работе с ними
Список документов, которые изменятся и аннулируются после утверждения и введения в действие извещения


Рассмотрим документооборот в архиве TechnologiCS.

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

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

Ответственным же за изменение статуса документа логично сделать именно разработчика, как самое заинтересованное лицо.

Маршрутизация документа в электронном архиве


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

История разработки извещения


Когда документ прошел все проверки и согласования, утвержден, зарегистрирован и введен в действие, перевести его в статус «В разработке» уже невозможно. Для внесения в действующие документы изменений следует создавать новые версии и согласовывать соответствующие ИИ. Конечно, перевод документа на доработку логичнее поручить опять-таки именно разработчику, а не проверяющему, поскольку именно разработчик решает, изменять проект документа или не изменять, а также дает дополнительные разъяснения, способствующие принятию именно этого варианта и/или изменению другого проекта документа.

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

Рассмотрим нормоконтроль и электронный документооборот.

Если преимущества использования электронного документооборота по сравнению с бумажным на этапах проверки/согласования очевидны, то на этапах утверждения и нормоконтроля, как показывает практика, они никак не проявляются. Во-первых, работа с документом здесь ведется в строгой последовательности в соответствии с ЕСКД. Во-вторых, подписи нормоконтролера и утверждающего имеют юридическую силу лишь на бумажном подлиннике, поэтому проставлять их сначала на электронном документе в базе данных, а затем на соответствующем бумажном носителе (или наоборот) – это значит дублировать одни и те же действия и дополнительно загружать персонал.

В соответствии с ГОСТ 2.111-68 (Изм. № 3), одной из задач нормоконтроля является соблюдение в конструкторской документации норм, требований и правил, установленных в стандартах ЕСКД и в других нормативных документах. Таким образом, при проведении нормоконтроля проверяется не только содержание, но и оформление документа. Осуществление нормоконтроля электронного оригинала документа вызывает определенные трудности.

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

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

Таким образом, электронная подпись нормоконтролера не может заменить подлинную, а следовательно, ее не имеет смысла проставлять в процессе электронного документооборота.

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

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

В соответствии с ГОСТ 2.111-68 (Изм. № 3) нормоконтроль конструкторских документов рекомендуется проводить в подлинниках при наличии всех подписей лиц, ответственных за их содержание и выполнение, кроме утверждающей подписи руководителя организации. При этом «документацию, утверждаемую руководителем организации, нормоконтролер визирует до передачи на утверждение и подписывает в установленном месте после утверждения».

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

Таким образом, к моменту простановки подписи утверждающего на бумажный подлинник существует два информационных объекта: документ в электронном архиве с электронными подписями проверяющих/согласующих и документ на бумажном носителе с тем же составом подлинных подписей и визой нормоконтролера. Затем в соответствии с ЕСКД подлинник, подписанный утверждающим и нормоконтролером, сдается в архив, а соответствующий электронный документ нормоконтролер переводит в статус «На учете». Так обеспечивается одинаковое состояние электронных и бумажных носителей идентичной информации.

Рассмотрим учет документов и актуализация информации в электронном архиве.

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

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

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

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

Рассмотрим преимущества TechnologiCS при использовании в качестве системы электронного документооборота.

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

Перед пользователями электронного архива TechnologiCS дополнительно открываются следующие возможности:
- быстрый поиск необходимых документов;
- эффективный доступ к документам и соответствующим извещениям;

Версии документа и извещение, связанное с одной из них


- возможность доступа ко всем документам, изменяемым и аннулируемым данным извещением;

Документы, связанные с извещением


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

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

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

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

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

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


Источники:
1. Чилингаров, К., Штейнбрехер, А. TechnologiCS// CADmaster, №5(5), 2000
[http://csf.ru/file/BIUjemrCuIDDecwN8299133/cm_05_technologics.pdf]
2. Докучаев, Д., Каменнова, М., Новожилов, О. Внедрение информационной системы как способ совершенствования бизнес-процессов предприятия// CADmaster, №1(26), 2005
[http://csf.ru/file/lVSKgTSXxdAKGEEE8299138/cm_26_vnedrenie.pdf]
3. Бобов, П. Электронный документооборот в TechnologiCS: результаты внедрения на крупном предприятии// CADmaster, №3(33), 2006
[http://csf.ru/file/LHxLIKnIZSiirVpW8299129/cm_33_technologics.pdf]

Автор: Челябэнергопроект
Дата: 22.07.2009

Комментарии специалистов Челябэнергопроект:
Нет
Статьи

смета проектных работ
©Челябэнергопроект – проектные работыinfo@chepr.ru, 2007-2013
DRA.RU - проектирование сайта под ключ; системный администратор ООО «Челябэнергопроект»
Главная|О компании|Стратегия|
Компетенция / услуги|Контакты
Сертификат качества