В последнее время на Хабре наконец-то стали появляться статьи об автоматизации делопроизводства и, в частности, о системах электронного документооборота. На написание этой статьи меня вдохновили две другие:
За что отдельная благодарность их авторам, выраженная в виде плюса к карме.
Я в свою очередь хочу рассказать об опыте внедрения систем электронного документооборота на базе платформы SharePoint. Я постаралась сосредоточиться на рассказе о подходе, который мы использовали при решении нашей задачи. Возможно, для кого-то он будет полезен.
Я неоднократно встречала в сети посты о том, можно ли автоматизировать документооборот на SharePoint. Мнения были разные и все сводились к одной простой мысли: да, но это решение будет стоить очень дорого за счет большого количества кода, связанного с определенным набором ограничений SharePoint.
Последние 3 года я работаю аналитиком в направлении SharePoint, в том числе и на проектах СЭД. И каждый раз, встречаясь с новым заказчиком, я слышу одно и то же требование: «Мы хотим систему, которую сможем развивать сами». Если идти по первому пути — по пути реализации требований силой .NET программистов, то мы получим хоть надежную СЭД, но практически не решающую следующие потребности любого заказчика:
- Реакция на изменения бизнеса. Заказчик не сможет оперативно изменять функционал при изменении бизнес-логики. Для этого ему будет просто необходимо связаться с производителем СЭД, заключить с ним договор (а в некоторых компаниях договоры заключаются годами) и только после этого внести изменения в свою систему;
- Изменение функционала своими силами. Возможно, оно и не понадобится заказчику. Возможно, он так же придет к вам и закажет техподдержку. Но сама по себе невозможность таких самостоятельных изменений создает ощущение зависимости от подрядчика, нахождения у него «на игле». А хорошо организованный бизнес сторонится подобных зависимостей;
- Быстрое развитие. В случае стремительного роста бизнеса, СЭД должна уметь так же быстро расти вместе с ним. Если уникальный проект, который был сделан для данной конкретной компании, не имеет в своей архитектуре определенной подушки для развития функционала, то данная СЭД погибнет при первом значительном росте требований.
Если у вас не 1, а 40 проектов СЭД на SharePoint, то все вышесказанное усугубляется еще больше, выливается в дорогущую гарантию по каждому из проектов и в еще более дорогую техническую поддержку.
Мы пошли по альтернативному пути, «вынеся за скобки» весь код в платформу и выстроив такую схему реализации проектов, в которой внедрение решения полностью ложилось бы на аналитика или внедренца.
Учитывая определенные ограничения SharePoint и специфику требований к СЭД, такая платформа должна была предоставлять следующие возможности:
- Свою совместимость с SharePoint Foundation (иначе решение будет просто не по карману малому и среднему бизнесу);
- Интерфейс для настройки форм;
- Интерфейс для настройки параметров отображения столбцов;
- Динамическое отображение столбцов (очень критично при проектировании систем документооборота);
- Интерфейс для настройки отображения кнопок рабочего процесса;
- Возможность добавления связанных списков непосредственно на форму;
- Иерархическое представление групп SharePoint (а иначе говоря — организационная структура);
- Более сложные типы данных (доработка требовалась как минимум для типа данных «Пользователи и группы» и «Подстановка»);
Все эти возможности и объединились в платформе, значительно расширяющей стандартные возможности SharePoint.
Для реализации бизнес-процессов мы не стали изобретать велосипед, а воспользовались разработкой крупнейшего партнера Microsoft в области проектирования бизнес-процессов Nintex Workflow 2010.
В результате исчезла проблема недопонимания между разработчиком и аналитиком, снизились затраты на разработку спецификации, реализация требований к процессам стала более четкой, реакция на изменения ускорилась.
Этот подход уже привел к массе положительных для обеих сторон результатов:
- Уменьшилось время внедрения системы (как результат — значительное уменьшение стоимости внедрения);
- Появилась возможность развития системы ИТ-отделом заказчика;
- Снизилось количество мелких обращений в техподдержку (тривиальные изменения заказчики стали проводить сами);
- Снизилась стоимость технической поддержки проектов;
- Снизились затраты на гарантийное сопровождение проекта (как результат — уменьшение стоимости внедрения);
- Снизилась или исчезла зависимость заказчика от производителя системы;
- Снизилась зависимость производителя системы от наличия в штате .NET разработчиков (внедрение проекта останавливается только в случае, когда заболевают все разработчики, аналитики и внедренцы) и т.д.
Когда платформа достигла максимальной стабильности, «за скобки» был вынесен и огромный блок регулярно повторяющейся функциональности. В результате на свет появилась тиражируемая версия решения СЭД (а в дальнейшем — других распространенных решений по автоматизации бизнеса).
Если абстрагироваться от российских реалий и хаоса, который учиняют многие компании при организации бумажного делопроизводства (который при неправильном подходе к автоматизации плавно перетекает в делопроизводство электронное), то жизненный цикл документа можно кратко обрисовать следующей схемой.
Таким образом, даже при условии разного рода деятельности, численности штата и специфических требований заказчика, объем функциональности, которую можно вынести в прототип внедряемой системы электронного документооборота, довольно внушительный. И архитектура решения могла бы выглядеть как-то так:
При таком подходе система обрастает уникальными требованиями заказчиков незначительно. А заказчики в свою очередь могут просто подкорректировать регламенты своей организации под действующее законодательство, таким образом, сэкономив на внедрении немалую сумму.
Надо сказать, что для реализации этого проекта потребовалось без малого 2 года и огромное количество человекочасов. Но результат превзошел все ожидания и полностью оправдал вложенные силы, доказав скептикам, что организация делопроизводства компании на SharePoint возможна и вполне безопасна для нервов и бюджета.
На данном этапе внедрение СЭД средней сложности составляет от 2х недель до 2х человекомесяцев. SharePoint, вопреки всеобщему мнению, прекрасно выдерживает большие нагрузки (500-600 одновременно работающих пользователей, 1000-1500 документов/рабочий день, 6000-8000 задач пользователей/рабочий день).
Автор: JuliyaErina
