Проектный документооборот. Внедрение для себя
08.10.2014

Проектный документооборот. Внедрение для себя

Статья Михаила Киреева, руководителя отдела разработки департамента 1С ГК "КОРУС Консалтинг", посвященная проблемам документирования, повторного использования, накапливания базы знаний, учета исполнения задач и тд.

Занимаясь разработкой и внедрением автоматизированных информационных систем (АИС), анализируя и выстраивая бизнес-процессы заказчиков, департамент 1С ГК «КОРУС Консалтинг» сам столкнулся с проблемами документирования, повторного использования, накапливания базы знаний, учета исполнения задач и тд. В данной статье мы рассказываем, как эти проблемы были решены. Это не пошаговая инструкция, а рассказ о личном опыте: как имея ограниченные ресурсы, но знания и умения, которые используются ежедневно, можно получить требуемый результат.

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


1. функциональные заказчики являются сотрудниками того же коллектива, что и потенциальные исполнители, а в некоторых вопросах это может быть один и тот же человек. В этой ситуации очень важно четко разделять свои действия в каждой из ролей и всегда руководствоваться правилом разумной достаточности.
2. у внутреннего проекта приоритет априори ниже, чем любого внешнего. Для реализации проекта возможно привлекать только тех исполнителей, которые свободны от производственных задач. Оптимальным является решение максимума задач внутреннего проекта в процессе выполнения работ по внешнему, но только чтобы это не отражалось на заказчике.
3. в качестве программного обеспечения нужно выбирать только те продукты, которые полноценно и оперативно поддерживать самостоятельно. Также они обязательно должны обладать веб-интерфейсом, чтобы сотрудники имели доступ из любого места, где есть Интернет, независимо от возможности подключиться к серверам через VPN.

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

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


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

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


При выборе базового ПО мы руководствовались следующими критериями:

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


Посмотрев несколько систем в той или иной степени удовлетворяющих выдвинутым критериям, среди которых были такие, как «Битрикс24», «ПланФикс», «1С: ITIL», «1С: СППР», «1С: Корпоративный документооборот», мы остановились на «1С: Документооборот 8» по следующим причинам:

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


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

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


Когда все организационно-подготовительные вопросы были решены, мы перешли к проработке методологической основы, регламента,  структуры и правил заполнения объектов системы. Таким основополагающим документом стал специально разработанный при старте производственного проекта документ «Регламент проведения разработки АИС», который отражал следующие правила:

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


По данным документа была проработана и заведена НСИ, определена структура справочников (проекты, файлы, внутренние документы), настроены параметры системы. Стоит отметить, что на основании документа мы сделали шаблон, который теперь используется в каждом проекте.

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

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

  • Регламент создания в АИС проекта и пользователя;
  • Порядок работы руководителя проекта в АИС.


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