Занимаясь разработкой и внедрением автоматизированных информационных систем (АИС), анализируя и выстраивая бизнес-процессы заказчиков, департамент 1С ГК «КОРУС Консалтинг» сам столкнулся с проблемами документирования, повторного использования, накапливания базы знаний, учета исполнения задач и тд. В данной статье мы рассказываем, как эти проблемы были решены. Это не пошаговая инструкция, а рассказ о личном опыте: как имея ограниченные ресурсы, но знания и умения, которые используются ежедневно, можно получить требуемый результат.
Проект по организации внутреннего документооборота – это такой же проект, как и многие другие, но при его реализации есть ряд нюансов (начальных условий), которые необходимо учитывать:
1. функциональные заказчики являются сотрудниками того же коллектива, что и потенциальные исполнители, а в некоторых вопросах это может быть один и тот же человек. В этой ситуации очень важно четко разделять свои действия в каждой из ролей и всегда руководствоваться правилом разумной достаточности.
2. у внутреннего проекта приоритет априори ниже, чем любого внешнего. Для реализации проекта возможно привлекать только тех исполнителей, которые свободны от производственных задач. Оптимальным является решение максимума задач внутреннего проекта в процессе выполнения работ по внешнему, но только чтобы это не отражалось на заказчике.
3. в качестве программного обеспечения нужно выбирать только те продукты, которые полноценно и оперативно поддерживать самостоятельно. Также они обязательно должны обладать веб-интерфейсом, чтобы сотрудники имели доступ из любого места, где есть Интернет, независимо от возможности подключиться к серверам через VPN.
Перед самым стартом проекта по созданию внутреннего документооборота были сформулированы те ключевые задачи и проблемы, которые должна была решить новая система на первом этапе:
- единое хранилище проектной документации (технические задания и отчеты об обследования, задания на разработку и программы испытаний, протоколы и отчеты менеджеров проектов, и т.д.) в разрезе проектов с возможностью их классификации и версионированием;
- организация управления разработкой, внедряемой АИС. Как минимум все задания по модификации системы должны были фиксироваться с маршрутизацией: постановщик, исполнитель, проверяющий, контролирующий. К заданиям обязательно нужно было иметь возможность прикреплять проектные документы, являющиеся основанием или результатом их выполнения. Также в заданиях необходимо было отражать планируемые срок и трудоемкость выполнения для обеспечения функции контроля.
- повторное использование наработок, как в части подготовки проектной документации, так и в части реализованных ранее доработок АИС. Для решения этой задачи не достаточно собрать базу знаний, необходимо иметь возможность с этой базой работать: различные инструменты поиска информации по критериям, в том числе и полнотекстовый поиск по хранимым в системе проектным документам.
- обеспечение перевода внедренной АИС на сервисное обслуживание. Система должна реализовывать имеющийся внутри компании регламент передачи проекта (проектной документации) на сервисное обслуживание. Сотрудники, осуществляющие сопровождение систем заказчика, должны иметь доступ к информации по всем его текущим и завершившимся проектам внедрения.
Определившись с задачами, необходимо решить, как проводить внедрение и на каком ПО. В качестве «полигона» был выбран крупный проект по производственному учету, оперативному планирования производства, а также блокам расчета зарплаты, кадрового учета, управления закупками и продажами, который отличался следующими положительными особенности:
- сформулированные ранее задачи так или иначе пришлось бы решать в различные периоды жизненного цикла проекта;
- команда проекта была достаточно большая, что обеспечило необходимую выборку для опытной и промышленной эксплуатации;
- объем проектной документации был достаточно большой и разнородный;
- предполагался существенный объем функциональных доработок системы в каждой из областей автоматизации учета;
- роль системного архитектора и руководителя группы разработки на проекте довелось исполнять мне, что позволило бы оперативно реагировать на вопросы, пожелания и инциденты;
- команда проекта (и что важно руководитель проекта) были заинтересованы в успешной реализации внутреннего подпроекта или как минимум не саботировали его.
При выборе базового ПО мы руководствовались следующими критериями:
- требуемый функционал должен быть максимально полно представлен с точки зрения решаемых задач;
- обязательна возможность доступа в систему из любого места, где есть Интернет (веб-клиент, либо специальный тонкий клиент);
- должна быть широкодоступна документация и дополнительные материалы (вебинары, видеоуроки) к системе и/или наличие оперативной службы поддержки. Это могло бы снизить затраты на настройку и запуск системы в промышленную эксплуатацию.
- пользовательский интерфейс должен быть интуитивно понятен, а еще лучше знаком большинству будущих пользователей. Это снижает затраты на поддержку пользователей в промышленной эксплуатации;
- совокупная стоимость владения должна быть минимальна.
Посмотрев несколько систем в той или иной степени удовлетворяющих выдвинутым критериям, среди которых были такие, как «Битрикс24», «ПланФикс», «1С: ITIL», «1С: СППР», «1С: Корпоративный документооборот», мы остановились на «1С: Документооборот 8» по следующим причинам:
- функционально система удовлетворяет предъявленным требованиям;
- нашим специалистам уже доводилось работать с этим продуктом;
- при необходимости штатные разработчики смогут доработать систему.
Оценив функциональные возможности, было принято решение, что на первом этапе дорабатывать имеющийся функционал системы нет необходимости. Единственной доработкой по принципу «подсистема-сбоку» планировали реализовать интеграцию с системой ServiceDesk, чтобы облегчить работу службе поддержки. Из имеющегося типового функционала мы определили следующий контур внедрения:
- Подсистема совместная работа: корреспонденты, проекты, проектные задачи, задания исполнителям;
- Внутренние документы, виды документов, файлы, тома хранения файлов, категории, поиск документов и файлов;
- Структура предприятия, должности, пользователи, группы доступа;
- Управление процессами: процесс «поручение», роли, шаблоны процессов, маршрутизация.
Когда все организационно-подготовительные вопросы были решены, мы перешли к проработке методологической основы, регламента, структуры и правил заполнения объектов системы. Таким основополагающим документом стал специально разработанный при старте производственного проекта документ «Регламент проведения разработки АИС», который отражал следующие правила:
- Общая информация по проекту: упрощенное наименование, сокращенный буквенный код, предметная область, используемые типовые и отраслевые системы, ключевые задачи проекта, руководитель проекта, состав проектной команды, каталог хранения файлов проекта;
- Файловая система проекта: структура каталогов, правила именования файлов, правила именования баз данных на сервере приложений;
- Регламент создания файлов поставки и обновления конфигурации;
- Регламент добавления новых и изменения существующих объектов метаданных конфигурации;
- Регламент комментирования кода.
По данным документа была проработана и заведена НСИ, определена структура справочников (проекты, файлы, внутренние документы), настроены параметры системы. Стоит отметить, что на основании документа мы сделали шаблон, который теперь используется в каждом проекте.
Поскольку было принято решение на первом этапе внедрять типовой функционал без доработок, а также тот факт, что наши пользователи имели достаточную компетенцию в использовании информационных систем, это позволило нам совместить опытную эксплуатацию с промышленной и начать применять систему внутреннего документооборота параллельно со стартом стадии разработки по производственному проекту.
В результате опытной эксплуатации мы выработали два ключевых документа, которые позволяют нам подключать к работе в системе новые проекты и пользователей:
- Регламент создания в АИС проекта и пользователя;
- Порядок работы руководителя проекта в АИС.
Дальнейшее тиражирование системы на другие проекты не вызывает никаких сложностей. В будущем мы планируем в полном объеме использовать функционал, связанный с планированием исполнителей и трудозатрат по проектным задачам, вести учет рабочего времени сотрудников, а также собираемся осуществлять в системе весь документооборот, а не только проектный.