Закрыть
Логин:
Пароль:
Забыли свой пароль?
Регистрация
Войти как пользователь
Вы можете войти на сайт, если вы зарегистрированы на одном из этих сервисов:

DOCFLOW - теория и практика электронного документооборота. Все о ECM и СЭД (системы электронного документооборота), ЭП

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

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

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

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

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

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

  • требуемый функционал должен быть максимально полно представлен с точки зрения решаемых задач;
  • обязательна возможность доступа в систему из любого места, где есть Интернет (веб-клиент, либо специальный тонкий клиент);
  • должна быть широкодоступна документация и дополнительные материалы (вебинары, видеоуроки) к системе и/или наличие оперативной службы поддержки. Это могло бы снизить затраты на настройку и запуск системы в промышленную эксплуатацию;
  • пользовательский интерфейс должен быть интуитивно понятен, а еще лучше знаком большинству будущих пользователей. Это снижает затраты на поддержку пользователей в промышленной эксплуатации;
  • совокупная стоимость владения должна быть минимальна.
Посмотрев несколько систем в той или иной степени удовлетворяющих выдвинутым критериям, среди которых были такие, как «Битрикс24», «ПланФикс», «1С: ITIL», «1С: СППР», «1С: Корпоративный документооборот», мы остановились на «1С: Документооборот 8» по следующим причинам:

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

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

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

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

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

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

Поделиться:
Автор текста: Михаил Киреев




КАЛЕНДАРЬ
ПОСЛЕДНИЕ НОВОСТИ
21.06.2019
TESSA 3.3 – новые горизонты СЭД
Компания Syntellect объявила о выпуске официального релиза СЭД TESSA версии 3.3.
В новой версии платформы расширены возможности легкого клиента, обеспечена поддержка разных часовых зон и внесено более сотни других улучшений.

28.03.2019
Финансы уйдут в электронный документооборот
На рассмотрение государственной думы РФ вынесен законопроект о введении электронного документооборота в российских организациях. При создании электронных копии бумажных документов, оригиналы нужно будет хранить всего год.

28.03.2019
В ожидании цифрового прорыва
Как выбраться из «колеи», в которой, согласно институциональной теории, движется, увязнув всеми колесами, Россия? Ответ на этот вопрос эксперты ищут не первый год. Вряд ли есть одно решение, но, возможно, в этом стране помогут технологии: отечественная математическая школа всегда высоко ценилась во всем мире, да и IT-отрасль в России развита сильнее прочих. Во всяком случае, именно на их развитие делают ставку власти: от направления «Цифровые технологии» нацпроекта «Цифровая экономика» они ждут настоящего прорыва. Впрочем, его успех, по мнению экспертов, будет зависеть от синхронизации процесса цифровой трансформации во всех российских регионах.