Содержание к диссертации
Введение
1 Анализ применения коммерческих систем инженерного документооборота для управления проектной деятельностью в проектной организации
2 Инженерный документооборот в проектной организации
2.1 Концептуальное описание структуры проектной деятельности и 29 потока инженерной документации ПИО
2.2 Особенности Нiech технического документирования в ПИО на примере ОАО «ТомскНИПИнефть»
2.3 Описание инженерного документооборота выполнения проектных работ с использованием еЕРС нотаций
2.4 Разработка типовых шаблонов управления проектными работами
3 Автоматное описание структурных особенностей проектной деятельности
3.1 Абстрактное автоматное описание проектной деятельности и инженерных документов
3.2 Формальное описание потока работ и документов в ПИО 64
3.3 Формализация управления СИД на основе дискретно событийного описания
4 Разработка автоматной структуры супервизора СИД ПИО 74
4.1 еЕРС – структура супервизора СИД ПИО 77
4.2 Преобразование ЕРС-модели проектной деятельности в сеть Петри
4.3 Верификация управляемости СИД с использованием сети Петри
5 Управление проектной деятельностью с использованием СИД
5.1 Ситуационное описание проектной деятельности 100
5.2 Сглаживание ресурсов проектных работ в СИД 106
5.3 Модульная реализация ПО СИД 109
Заключение 133
Список литературы
- Концептуальное описание структуры проектной деятельности и 29 потока инженерной документации ПИО
- Описание инженерного документооборота выполнения проектных работ с использованием еЕРС нотаций
- Формальное описание потока работ и документов в ПИО
- Верификация управляемости СИД с использованием сети Петри
Концептуальное описание структуры проектной деятельности и 29 потока инженерной документации ПИО
Правильно организованный документооборот в организации повышает его конкурентоспособность и эффективность работы. Компьютерные системы управления документами позволяют не только облегчить формирование нужного формата документа, но и обеспечивают непрерывный контроль его жизненного цикла (рис.2). В результате руководством и исполнителями отслеживаются, корректируются и управляются все необходимые действия над документом в течение всего периода существования на всех его траекториях перемещения в организации.
Таким образом, внедрение систем автоматизации делопроизводства повышает уровень эффективности работы с документами, сокращает объем времени, необходимого для обработки документации, вследствие чего ведет к увеличению производительности труда
Однако каждая проектная организация имеет свои особенности, методы управления и контроля. Поэтому готовая (коммерческая) автоматизированная система управления документооборотом (АСД) не всегда может хорошо «наложиться» на уже сформированную организационную культуру проектной организации. В результате решение проблем автоматизированного управления документооборотом в ПИО приобретает огромное значение.
Для преодоления сложностей с внедрением АСД поставщики услуг автоматизации готовы осуществлять подстройку коммерческих систем автоматизации делопроизводства под конкретную организацию, адаптировать их под конкретного заказчика, но такая работа опять же имеет свои ограничения из-за специфики используемого в ПИО программного обеспечения (ПО). Настройка таких программных продуктов – очень трудоемкий и длительный процесс, а последующая адаптация АСД под изменяющиеся условия выполнения проектной деятельности, требует индивидуальной команды сопровождения, которую не готовы содержать ни исполнитель, ни ПИО.
Рынок автоматизированных систем делопроизводства начал формироваться около 30 лет назад. В настоящее время на рынке представлено три категории систем:
1. Системы западного производства (русифицированные версии). Примерами таких систем являются ЕМС Documentum компании Documentum [12], Lotus Domino/Notes корпорации IBM (IBM Collaboration Solutions) [13], DocuLive концерна Siemens [14] и др.
2. Российские системы, базирующиеся на программе Lotus Domino/Notes. Среди них OfficeMedia компании «Интер-Траст» [15], «Эскадо» от «Интерпроком ЛАН» [16], «Золушка» Научно-технологического центра Института развития Москвы и др.
3. Полностью российские разработки. Это АСД, полностью разработанные российскими фирмами-производителями, на базе промышленных СУБД. Наиболее известными из них являются система «ДЕЛО» компании «Электронные офисные системы», «Кодекс» Центра компьютерных разработок, LanDocs от ЛАНИТ, OPTIMA-WorkFlow производства группы компаний «Оптима», DocsVision [19] от одноименной компании "DocsVision" и ряд других. Большинство из отечественных АСД сочетают основные функции, такие как обработку и хранение документов, их регистрацию, управление потоками работ, осуществление контроля исполнения, организацию поисковой системы по атрибутам, а также возможность полнотекстового поиска, работу с взаимосвязанными документами, интеграцию их с другими программными продуктами, в том числе с системой электронной почты, объединение документов в дела, регистрацию и ограничение прав доступа и т.д.
Известно большое число обзоров сравнительного анализа автоматизированных систем управления документооборотом в различных областях и секторах общечеловеческой деятельности [20-23].
Для автоматизации проектной деятельности в небольших ПИО могут использоваться так называемый «open source»-инструментарий типа JIRA [28], обеспечивающий коллективную работу проектировщиков с запросами в рамках проекта, а также такие облачные приложения, как, например, сервис Clarizen [29].
Для управления проектной деятельностью в больших проектных организациях используют технологию Oracle Primavera, многопользовательскую версию MS Project - Microsoft Office Enterprise Project Management Solution, а при внедренных автоматизированных комплексах ERP-класса таких как SAP или 1C, модули типа «Управление Проектным Офисом».
Достоинством ERP-решений является возможность интеграции модулей ERP-систем между собой, что позволяют легко синхронизировать управление проектами с учетными задачами ПИО.
В большинстве ПИО готовую техническую документацию хранят в электронном архиве. Обычно он создается на портале ПИО (рис. 3). Примером такого решения является система документооборота Search [30]. Она позволяет создавать архив технической документации предприятия на основе СУБД Oracle или InterBASE. Так, например, архив документов программы Search организован в виде базы данных, содержащей сами документы и информацию, необходимую для их идентификации. Система позволяет создавать неограниченное количество архивов, каждому из которых можно присвоить различные свойства. Свойства архивов обусловливают правила работы пользователей с документами внутри архивов.
Описание инженерного документооборота выполнения проектных работ с использованием еЕРС нотаций
Описание: «Часть процесса потоков работ, в котором активность функции вызывается из другой части процесса или от внешней среды». «Устойчивый триггер» удерживает процесс неактивным, пока не будет получен соответствующий сигнал. Хотя нотация еЕРС обеспечивает поддержку нескольких входных событий, которые могут быть использованы в качестве устойчивых триггеров, тем не менее, часто не представляется возможным провести различие между ними (обычными входными экземплярами событий и триггерами с включением последующих активностей). Поэтому процессы в бизнес-моделях, построенных с применением традиционных еЕРС-средств активности функций, задаются обычными средствами модели ARIS. Шаблон 11 «Ациклическая синхронизация слияния»
Описание: «Часть процесса в потоке работ процесса, в котором сходятся два или более путей, которые расходились в начале процесса так, что в одной или нескольких ветвях присутствуют элементы принятия решения о выполнении активностей на основании локальных данных процесса». Если задействован более чем один путь, применяется синхронизация активных потоков. Если задействован только один поток, альтернативные ветви сходятся без синхронизации. Шаблон предполагает выполнение операции без циклов.
Применение шаблонов при модельном описании подобно использованию готовых библиотек кода. Правильно подобранный шаблон модельного описания процесса проектирования позволяет, отыскав удачное решение, пользоваться им снова и снова. Набор шаблонов помогает разработчику выбрать наиболее подходящую модель, описывающую процесс проектирования.
Дополнительная польза от использования шаблонов состоит в возможности разработки программного обеспечения СИД на их основе. Так как шаблоны независимы от технологии реализации и могут быть повторно используемы, то это позволяет унифицировать разработку программного кода СИД.
1. На концептуальном уровне описания проектной деятельности можно заключить, что большая часть работы руководства по управлению проектом – это сбор и анализ инженерной информации о нём.
2. Большое число коммерческих программных средств, используемых для выполнения проектных работ, (в частности, Microsoft Project, или Open Plan, Spider Project и др.) могут обеспечить достаточно удобные средства ввода, структурирования и анализа части инженерной информации, касающейся автоматизации плановых расчётов и подготовки отчётов и, таким образом, решить следующие задачи: подготовить инженерные документы планов выполнения проекта; установить критические пути с учётом ресурсов, необходимых для выполнения предусмотренных проектом работ и устанавливают необходимый распорядок рабочего времени; подготовить документы, согласующие использование ресурсов; обеспечить инженерное согласование использования ресурсов, подготовку документов о переносе части работ на более поздние сроки, если некоторые ресурсы в дефиците.
Они позволяют выполнять установленные в ПИО правила подготовки в проектном производстве исходной информации, необходимой для обеспечения руководства проектной деятельностью в целом.
Визуальный формат еЕРС-нотации выполнения проектных работ является хорошей практикой (Best Pratic), обеспечивающей понятность и непротиворечивость семантики проектной деятельности. Такое описание обладают существенным достоинством при оперативном отслеживании изменений требований спецификаций при выполнении проектных работ.
Описание проектной деятельности в виде шаблонов позволяет установить в ПИО событийную еЕРС - траекторию выполнения проектов в свернутом виде, позволяющим упростить описание проектной деятельности.
Так как при разработке систем класса СИД в ПИО силами самой организации, как правило, высок риск возникновения ошибок на стадии разработки ПО и это связано, прежде всего, с непрофильной подготовкой ИТ-специалистов ПИО, то для устранения возможных некорректностей в работе СИД представляется целесообразным обеспечить необходимую строгость структурных решений для программных модулей СИД с использованием формальных простых математических средств в виде автоматных моделей.
Автоматные модели программ [46] широко используются для создания управляющих систем, поскольку автоматы позволяют просто и наглядно представлять логику работы системы и уже поэтому они перспективны для использования в ПИО при доработке коммерческих программ управления инженерным документооборотом. Кроме того, с использованием автоматных моделей можно формализовать и даже автоматизировать верификацию сложной программной системы [55, 56].
Основная идея использования таких моделей сводится к следующему: поскольку доработка сложного программного комплекса (каким является СИД) в силу объективных или субъективных причин в ПИО оказывается трудно верифицируемой, то в системообразующем плане можно воспользоваться более простой ее моделью или совокупностью моделей, описав в них только то, что является главным, и, обеспечив при этом необходимое соответствие установленным регламентам, а затем уже на основании таких моделей осуществить кодирование модулей программной системы и проверку их правильности в каждом модульном приближении. В [53-55] отмечается, что такой подход особенно хорошо работает на практике, если саму модель и набор тестов для нее можно строить по частям, постепенно наращивая набор свойств реальной системы, отражаемых в модели, и, соответственно, осуществляя необходимую проверку и продвижение кодирования программной системы.
Формальное описание потока работ и документов в ПИО
Действительно, проектная деятельность ПИО представляет собой множество партионных (batch) процессов. В соответствии с рекомендациями стандарта событийность таких процессов может быть описана в виде модели 12 состояний: «1-idle, 2-running, 3-complete, 4-pausing, 5-paused, 6-holding, 7-held, 8-restarting, 9- stopping, 10-stopped, 11-aborting, 12-aborted», смысловая сущность которых следующая:
1. Подготовленный. Состояние проекта, подготовленного для выполнения. Это возможное ожидание супервизорного СИД-указания о начале выполнения работ, появление (загрузка) в СИД исходных данных.
2. Запущенный. Состояние проекта, находящегося в работе. Это СИД-информация начала работ.
3. Завершенный. Состояние проекта с выдачей готовой документации заказчику. Это публикация инженерного документа СИД соответствующей формы.
4. Приостановленный. Состояние проекта при переходе его к ожиданию, к запросу частей проекта от смежных отделов, позволяющих продолжить работу. Это СИД- публикация инженерных документов у ответственных за выполнение проекта.
5. Ожидающий. Состояние ожидания частей проекта от смежных отделов и т.д. Возможное переключение на другие проекты. Это подготовка и отправка на рассмотрение СИД соответствующих инженерных документов, оповещение СИД ответственных исполнителей и руководства о статусе частей проекта.
6. Подготовленный к проверке. Состояние подготовленного к проверке проекта, отправка на рассмотрение проверяющим, нормоконтролю, согласование смежным отделам, главгосэкспертизы. Это публикация СИД у руководства соответствующей формы документа. 7. Проверяемый. Состояние проекта при проверке проверяющими, нормоконтролем, согласовании его со смежными отделами, с главгосэкспертизой. Это публикация СИД у руководства соответствующей формы документа.
8. Исправляемый. Состояние проекта в процессе исправления замечаний/ошибок, возврат к проектированию. Это публикация СИД у руководства соответствующей формы документа.
9. Согласуемый. Состояние проекта в процессе согласования актов приема, согласования объемов выполненных проектных работ при выполнении процедур обсуждения остановки проектирования по требованию Заказчика или иным причинам. Это публикация СИД у руководства соответствующей формы документа.
10. Остановленный. Состояние остановки проектирования по требованию Заказчика или иным причинам. Это публикация у руководства соответствующей формы документа СИД
11. Пересматриваемый. Состояние прерывания выполнения проекта. Это подготовка СИД документа к пересмотру исходных данных от Заказчика, сторонних организаций.
12. Отказ от выполнения проекта на основе первоначальных исходных данных в связи с изменением внешних или внутренних факторов. Это СИД документ о пересмотре исходных данных от Заказчика, сторонних организаций.
В рамках рассматриваемой модели документооборота состояние (idle) соответствует начальному состоянию, в котором находится документ, предписанный проекту после его инициализации. При представлении инженерного документооборота в виде совокупности состояний его начальное состояние это этап, когда можно говорить о том, что документ существует и ожидается супервизорное СИД-указание о начале выполнения проектной работы. Из приведенной схемы следует что, структурная событийность автомата выполнения проекта G может быть представлена в виде звездообразной архитектуры. Центральным событием в этой структуре является запущенный в работу, выполняемый проект. Основным циклом успешного проектирования является событийная последовательность «1-2-3», которая осуществляется после подготовки дела нового проекта, либо после изменения, обновления дела проекта, связанного с пересмотром договорных условий или с пересмотром исходных данных. Выполнение этой последовательности ведет к успешной завершаемости проекта. Все другие последовательности выполнения проекта связаны с «обременительными» событиями, притормаживающими или тормозящими выполнение проектных работ. После выполнения «обременительных» событий осуществляется продолжение проектирования в соответствии с исходным заданием.
Этап 2. В соответствии с регламентами ПИО устанавливается автоматная модель Н регламентного исполнения документов. Концептуальная проверка выполнения системных требований автоматной модели документа Н на основе методологии, описанной в [62], может быть выполнена путем последовательности действий над символами s супервизора S и проверки успешности осуществления всех переходов G(s). Это может подтвердить, что H(s) = True. В противном случае следует считать, что Н оказался не согласованным с G и, следовательно, формализм спецификации ДСС (СИД), определяющим регламент автомата документа Н =(Q ,Е,,8,,Т,Q m ,q 0 ) должен быть изменен.
Полученные еЕРС-описания управляющей части СИД состоят из трех типов узлов событий Е функций F и коннекторов С. Тип каждого коннектора устанавливается функцией Т є С - (or,xor,and). Отношение А специфицируется дугами, соединяющими функции события и коннекторы. Эти отношения попарно не пересекаются (непосредственно не соединяются меду собой две функции или два события). Кроме того, только события являются началом и концом еЕРС -диаграмм.
Такая модель позволяет установить и определить заданный (устанавливаемый руководством) набор управляющих команд СИД в виде строк событийности Ес инженерных документов, которые должны быть отработаны исполнителями, в соответствии с установленными в ПИО регламентами.
Семантическая верификация еЕРС модели управления проектной деятельностью осуществляется путем привлечения для ее разработки непосредственных исполнителей проекта. Как показывает практика СМК ПИО ОАО «ТомскНИПИнефть» разработку еЕРС описаний удобно выполнять в виде спецификаций в сценарном языке модельной системы APJS.
Верификация управляемости СИД с использованием сети Петри
Описание ситуации проектной деятельности обеспечивается набором характеризующих эту ситуацию показателей. Ключевую роль в СИД играет мониторинг ситуаций на основе семантики формального восприятия руководством проекта атрибутов инженерных документов.
Сложности с формализованным описанием проектной деятельности, как объекта управления посредством СИД, в сочетании с использованием показателей, имеющих качественный характер, предполагают использование, в основном, качественных решений, например, основанных на контроле возможных несоответствий проектной деятельности в потоке инженерной документации.
Для процессов проектирования характерно наличие атрибутных ограничений на такие несоответствия, например, Yimin и Yimax .
В случае выхода значений выходных переменных (инженерных показателей проекта) за допустимые пределы, с использованием СИД должна решаться задача поддержки возвращения их в допустимую область. При этом из-за инерционности процессов проектной деятельности, решение задачи возвращения в допустимую зону невозможно осуществить мгновенно и единым управленческим действием. Решение этой задачи приходится реализовывать как многооперационный процесс дискретного ситуационного управления проектной деятельностью, в ходе которого формируются управленческие действия с использованием инженерных документов. Задачей такого управления является приближение выходные показателей проекта к плановым значениям Yinom или, по крайней мере, удерживания их в допустимых границах Yimin и Yimax .
Одной из особенностей управления процессом проектирования на уровне СИД является то, что эффект управленческих решений проявляется не сразу. Это связано с тем, что в своей последовательности управленческих решений ситуация оценивается заинтересованным лицом, для которого сигналы обратных связей (оценки ситуаций) поступают с большой задержкой. Из-за этой особенности представляется целесообразным использовать в ПИО компьютерную систему мониторинга показателей проектной деятельности [83], систему сбалансированных показателей (ССП), которая способна повысить быстродействие контура обратной связи оценки ситуаций проектных работ.
После ввода показателя в допустимую область главная цель супервизора СИД изменяется: ею становится обеспечение гомеостаза процесса проектирования.
Исходя из опыта выполнения проектов в ПИО, в классе таких систем управления с помощью компьютерных средств в организации может быть создана база вариантов разрешения ситуаций, которые так или иначе связаны с удовлетворением установленных требований в операционной последовательности выполнения проекта.
В системе принятия решений "по ситуации" могут быть использованы два вида технологий управленческих решений: на логических правилах (нормативных требованиях) и исходя из предыдущего опыта (типовых ситуаций).
В процессе разработки СИД нормативные требования выполнения проектов учитываются в еЕРС-описаниях процессов проектной деятельности ПИО.
В логике принятия решений в СИД по типовым ситуациям пространство управления проектной деятельностью представляется как пространство, состоящее из ситуаций-прецедентов. При их использовании руководством проекта сравнивается описание распознаваемой ситуации с перечнем типовых ситуаций и осуществляется их идентификация. Поддержку их решений целесообразно осуществлять на основе вычисления степени близости распознаваемой ситуации с ситуациями, принадлежность которых к заданным классам известна. Часть этих решений фиксируется регламентирующей документацией. Другие накапливаются в качестве полезных решений в корпоративном портале. Таким образом, реализация и разработка системы ситуационного управления в СИД должны включать в себя:
Основные теоретические идеи ситуационного управления изложены в [49, 86-90], а в практике ПИО они используются на основе логики здравого смысла.
Эффективность ситуационного подхода к управлению проектной деятельностью может быть существенно повышена, а реализация формализована, если положить в ее основу принятие решений "по тенденциям" [92]. Эта технология предполагает, что состояние объекта управления (проекта) характеризуется совокупностью, так называемых сигнатур изменения, значений выходных показателей YieY и неуправляемых (но, наблюдаемых) входных переменных ек є Е (возмущений). Для идентификации и кодирования состояния проектных работ с применением двоичной системы с каждой переменной проектных работу также, как и в [92], свяжем две тенденции Г. и Г.+1. Индексы Т отражают разряд кода состояния который указывает на то, что у -ая тенденция присутствует в его описании, когда отклонение показателя принимает значение «истина», или отсутствует, если у -ый разряд кода состояния имеет значение «ложь».