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