+7 (812) 677 56 90

+7 (495) 647-50-46

08.10.2014

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Антон Колосов

Коммерческий директор

1c@korusconsulting.ru

+7 (495) 647-50-46,
+7 (812) 677-56-90

Задайте вопрос нашему эксперту