Построение системы технического и офисного документооборота в ООО «ТюменНИИгипрогаз»
История ООО «ТюменНИИгипрогаз» насчитывает более 45 лет. За это время компанией накоплен огромный опыт научных исследований и проектирования объектов инфраструктуры месторождений углеводородов — проведено множество геофизических исследований, созданы сотни проектов разработки месторождений, строительства скважин и обустройства месторождений с различными характеристиками. Немалые приобретенные знания, богатый опыт организации и выполнения работ позволили задуматься о типизации и стандартизации производственных процессов, и в 2000 году, после мероприятий по разработке внутренних стандартов организации (далее — СТО), ООО «ТюменНИИгипрогаз» получило сертификат соответствия системы менеджмента качества (далее — СМК) требованиям ISO серии 9000. Однако наличие утвержденных стандартов и сертификата соответствия еще не гарантирует того, что стандарты будут выполняться. Следовать стандартам, зафиксированным на бумаге, довольно сложно, а совершенствовать процессы и вносить изменения в стандарты практически нереально, если за их исполнением следит только человек, — ведь человеческий фактор никто не отменял. Логичным продолжением курса на стандартизацию и совершенствование стало принятие решения об автоматизации основных процессов научной и проектной деятельности. Начать решено было с проектного направления: количество информационных связей и разного рода документов, генерируемых по этому направлению, намного больше, чем по научным направлениям, поэтому эффект от автоматизации был бы заметен быстрее.
Оставим за рамками данной статьи этап выбора конкретной системы автоматизации — обо всей сложности и ответственности этого процесса, лучших практиках, полезных и вредных советах написано множество статей. Скажем лишь, что наиболее полно соответствующей тогдашним потребностям общества была признана система PartY Plus, разработанная российской компанией «Лоция Софт». В конце 2002 года, спустя 11 месяцев после начала проработки договора на поставку и настройку системы, автоматизированная система управления проектными данными (далее — АСУ ПД) была принята в эксплуатацию.
О компанииООО «ТюменНИИгипрогаз» — дочернее предприятие ОАО «Газпром», осуществляющее научную, проектную и производственную деятельность, головная организация по научному обеспечению производственной деятельности предприятий газовой промышленности в Западной Сибири. В рамках предприятия реализуется комплексный подход к разработке и обустройству газовых, газоконденсатных и нефтяных месторождений. Научные разработки и проектные решения ООО «ТюменНИИгипрогаз» используются на многих предприятиях Западной и Восточной Сибири, а промышленное оборудование, изготовленное на Экспериментальном заводе общества, применяется по всей стране. Отличительной особенностью ООО «ТюменНИИгипрогаз» является совмещение функций научного исследования, проектирования и производства. Это позволяет действовать более оперативно, претворяя в жизнь самые смелые и эффективные проектные решения. |
Несмотря на то что в рамках настройки платформы под нужды общества был реализован практически весь спектр бизнеспроцессов, единовременно перевести всех пользователей системы на ведение этих процессов в рамках АСУ ПД оказалось невозможно. Необходимо было своими силами проводить обучение пользователей, вносить некоторые изменения в настройку системы, следить за ходом внедрения и корректировать его. Поэтому руководство общества определило приоритетный процесс, который нужно было перевести на электронные рельсы в первую очередь, — обмен заданиями между смежными подразделениями. Этот процесс отличался большим числом участников и существенным объемом — в день выдавалось более 30 заданий, по каждому из которых исполнитель должен был собрать не менее пяти подписей (проверяющие в своем отделе, согласовывающие в принимающем отделе и главный инженер проекта, утверждающий задание). Ожидалось, что эффект от автоматизации данного процесса будет весьма ощутимым и быстро даст первые дивиденды от вложений в систему автоматизации.
Шаблон процесса выдачи задания в смежное подразделение
И ожидания полностью оправдались. Исполнители в проектных отделах осознали, что необходимости обходить всех согласующих лиц больше нет — их работа по выдаче задания свелась к его подготовке и отправке на проверку первому проверяющему. Каждая следующая пересылка задания осуществляется очередным участником процесса. Руководители различного уровня получили множество отчетов, позволяющих отслеживать процесс обмена заданиями между смежными отделами и контролировать сроки. Исполнители были избавлены от обязанности предоставлять каждое утвержденное задание для учета в диспетчерскую группу, сотрудники которой ранее отмечали выданные задания в бумажных планахграфиках. Все участники этого процесса смогли сконцентрироваться на выполнении своих непосредственных задач, тогда как функции учета проделанной работы и построения аналитических отчетов в различных разрезах взяла на себя система. Упростило повседневную работу проектировщиков и то, что все задания и приложения к ним теперь хранились централизованно — для поиска актуальных технических решений смежных отделов не нужно было просматривать сетевые папки компьютеров коллег из смежных отделов или хранить на своем столе стопки заданий по нескольким проектам со всеми приложениями. Для заданий в системе было выделено отдельное дерево, структура которого повторяла структуру комплекса проектирования: шифр, стадия проектирования, площадка, позиция по генплану. Естественно, были и сложности. В основном они были вызваны необходимостью изменить свои привычки при согласовании документов. Согласующие лица, не видя живой очереди из исполнителей, не торопились согласовывать документы в электронном виде. Благодаря некоторым административным и техническим методам сотрудники со временем привыкли проверять документы не тогда, когда ктото стоит над душой, а когда есть документы, требующие проверки. В целом автоматизация процесса обмена заданиями стала быстрой победой, которая показала выгоду от использования системы для сотрудников различного уровня. Впоследствии этот положительный опыт был одним из лучших аргументов «за» при обсуждении дальнейшего масштабирования системы.
Структура дерева проектно-сметной документации с примерами хранящихся документов
Благодаря применению функционала шаблонов процессов документооборота удалось добиться повторяемости процесса выдачи заданий в соответствии с принятыми СТО. Здесь стоит отметить, что по мере внедрения и масштабирования АСУ ПД некоторые СТО подвергались переработке. Причина не только в естественном изменении стандартов в целях постоянного совершенствования процессов, но и в том, что в ряде случаев в утвержденном СТО описание процесса ограничивалось уровнем, достаточным для понимания человеком. При переводе этого описания в конкретные настройки автоматизированной системы выявились формулировки, позволяющие вольную трактовку. Все эти формулировки были уточнены и зафиксированы — таким образом, автоматизация процессов сама по себе стала инструментом совершенствования СМК.
Следующим этапом внедрения системы стал архив готовой проектносметной документации. С точки зрения принципов работы этот архив представлялся схожим с архивом заданий: структура дерева проектов, шаблоны документооборота, отчеты о готовности комплектов чертежей. Всё это было реализовано в АСУ ПД и сдано в опытную эксплуатацию, однако успеха выдачи заданий повторить не удалось. Причина в том, что оформление и согласование комплектов чертежей в электронном виде оказались второстепенными задачами для проектировщиков. Основными же, естественно, остались оформление и согласование комплектов на бумаге. В результате комплекты в АСУ ПД сдавались в архив с отставанием в дветри недели от бумажных оригиналов, о контроле сроков сдачи комплектов по отчетам системы речи не шло — отчетность о сдаче бумажных комплектов тоже оставалась бумажной. Только по прошествии некоторого времени, когда ослабло сопротивление пользователей этой «двойной» работе, удалось принять административные меры, направленные на то, чтобы электронные комплекты сдавались в архив одновременно с бумажными. Но объем работы для проектировщиков от этого не уменьшился, поэтому проблема всё еще существует — в настоящее время прорабатываются возможные пути ее решения. Этот неудачный опыт, в сочетании с успехом выдачи заданий смежным отделам, показал команде внедрения, какое значение имеет своевременный отказ от дублирования на бумаге процессов, которые переведены в электронный вид.
Данные о выдаче заданий и готовности документации, имевшиеся в системе, безусловно, представляли большой интерес для исполнителей и руководителей среднего звена. Благодаря отчетам они могли оперативно получать информацию о степени готовности того или иного объекта проектирования в разрезе заданий или комплектов. Однако для заместителя генерального директора и главных инженеров проектов этот уровень информации оказался избыточным и мелким. Необходимо было предоставлять более укрупненные данные по отдельным заказам и даже по всему портфелю проектов. В системе на тот момент уже был ряд настроек для ведения информации по договорам в объеме, предусмотренном техническим заданием, но этого оказалось недостаточно для организации полноценной работы. Дело в том, что конечным элементом архива договоров был сам договор, хранивший информацию о стоимости, сроках и предмете договора, однако зачастую необходимо было предоставить информацию по входившим в состав договора этапам календарного плана, у каждого из которых были свои стоимость, сроки и перечень работ. Имея информацию о составных частях договора, можно было бы формировать более детальные аналитические отчеты, в том числе автоматически агрегировать информацию до уровня договора, тогда как автоматическая декомпозиция договора на этапы представлялась практически неосуществимой задачей. Таким образом, архив договоров был преобразован в архив этапов договоров, что позволило существенно расширить набор отчетов о планировании и исполнении договоров.
С внедрением архива договоров АСУ ПД уже не могла считаться системой только для проектных данных — началось ее распространение на другие аспекты производственной деятельности. Эта тенденция была продолжена с внедрением блока управления входящей и исходящей корреспонденцией и организационнораспорядительной документацией. Отдельной системы для архива корреспонденции на тот момент не существовало, поэтому было принято решение создать его на основе проверенной и принятой сотрудниками платформы. Были разработаны процедуры регистрации корреспонденции, визирования и пересылки исполнителям, постановки и снятия с контроля. Впоследствии были реализованы механизмы контроля для резолюций всех уровней исполнения (ранее письма на контроль мог ставить только генеральный директор) и связывания исходящих и входящих писем, что позволило просматривать цепочки писем по одной теме.
Автоматизированная система управления производственной деятельностью
По мере внедрения и масштабирования системы у пользователей начало формироваться понимание основных преимуществ от упорядочения хранения данных и организации коллективной работы с различными документами. Это привело к тому, что пользователи стали чаще обращаться к сотрудникам ИТслужбы с предложениями автоматизировать важные для себя процессы в среде АСУ ПД — за счет автоматизации они рассчитывали сделать критичные бизнеспроцессы более прозрачными, упростить и ускорить их выполнение. К числу таких процессов, реализованных в АСУ ПД, можно отнести следующие:
- хранение и создание новых редакций документов СМК;
- управление предупреждениями о несоответствии конструкторской документации;
- управление патентами на интеллектуальную собственность и заявками на регистрацию патентов и ряд других.
Одним из самых объемных процессов, разработанных в среде АСУ ПД по инициативе пользователей, можно считать процесс управления проведением тендеров на закупку и участием в конкурсах на выполнение работ. Изначально речь шла о создании архива конкурсов и тендеров с регистрацией всей необходимой информации о конкурсах, актуализацией их состояния и формированием необходимых отчетов, по сути — об инструменте для работы сотрудников одного подразделения. Уже в процессе разработки этого инструмента инициаторами высказывались сомнения в целесообразности применения платформы АСУ ПД и предложения рассмотреть готовые программные решения. Однако благодаря гибкости средств разработки Lotsia PDM Plus (такое название получила очередная версия PartY Plus), сотрудникам ИТслужбы удалось создать инструмент, не только полностью отвечающий требованиям пользователей, но и позволяющий оперативно вносить изменения в алгоритмы работы и отчетности. Важность последней возможности трудно переоценить, учитывая российские реалии и бурное развитие института конкурентных закупок. Более того, блок управления конкурсами и тендерами стал не просто инструментом для одного подразделения, а системой, с которой работают сотрудники практически всех подразделений компании, — зарегистрированные конкурсы проходят согласование с производственными подразделениями и процедуры оформления и сбора конкурсной документации в электронном виде. Как и в случае с договорными документами, доступ к конкурсной и тендерной документации имеют только уполномоченные пользователи системы.
Внедрение блока управления тендерами и конкурсами стало очередным шагом к формированию в рамках АСУ ПД единого информационного пространства проектного производства. В одной системе было реализовано управление конкурсами, тендерами и договорами, практически полный спектр процессов проектного производства, офисный документооборот — практически все основные этапы жизненного цикла договора на проект обустройства. И всё это — в едином интерфейсе с одинаковыми принципами работы, что избавляет пользователей от частого переключения между различными системами. Список задач для конкретного пользователя может содержать задачи из разных блоков: согласование задания от смежного отдела, доработку своего комплекта чертежей, подготовку ответа на входящее письмо, согласование участия в конкурсе и т.д. Такой же список видит руководитель подразделения — по всем своим сотрудникам, что упрощает оперативный контроль. Существенным преимуществом единой платформы является то, что различные блоки информации имеют перекрестные ссылки друг на друга. Например, в дереве конкретного проекта можно посмотреть список входящих писем по этому проекту, от договора на проектные работы — перейти к конкурсу, по итогам которого заключен этот договор, и т.д., оставаясь при этом в окне одного приложения.
Тем не менее одна система, несмотря на всю ее функциональность, не может удовлетворить все потребности компании — часть специальных функций логичнее реализовать в специализированных системах, при этом возникает задача интеграции разных систем, чтобы сохранить принцип единичного ввода данных и их наследования. Интеграционные возможности Lotsia PDM Plus позволили нам организовать обмен данными между АСУ ПД и рядом других систем, выполняющих разные задачи и построенных на различных технологиях, — системой управления финансовохозяйственной деятельностью на базе ERP «Галактика», корпоративной системой управления проектами на базе Microsoft Project Server, внутренним информационным порталом на основе Microsoft SharePoint. В одних случаях обмен данными выполнялся в автоматизированном режиме с участием человека, посредством обменных файлов, в других — полностью автоматически, с применением встроенного в систему сервера автоматических этапов.
Интерфейс рабочего места пользователя
Очевидно, что внедрение столь масштабной системы не могло обойтись без многочисленных затруднений и проблем; упомянутая выше несинхронность согласования документации — лишь одна из них. Другая проблема для пользователей — непривычность интерфейса системы и необходимость учиться работать с ним. На наш взгляд, корень проблемы не в самой системе, а в имеющемся у сотрудников опыте: система сравнивается с привычными программами, которые выполняют несколько иные функции, — от Word и проводника Windows до почтовых программ и MS Project. Специфика же АСУ ПД и Lotsia PDM Plus в целом состоит в том, что они объединяют в себе множество функций разных программ, и специалистам ИТслужбы компании нужно вместе с пользователями определить, какой функциональности не хватает, и корректно поставить задачу перед разработчиками платформы. Новые версии платформы с реализованными пожеланиями выходят достаточно часто, при этом существующая функциональность не нарушается. Как результат — платформа развивается, удовлетворяя все новые требования пользователей, а вместе с платформой развивается АСУ ПД, охватывая новые бизнеспроцессы и повышая прозрачность и оперативность производственной деятельности, — таким образом, выполняются задачи, выдвигаемые руководством компании сегодня.