Зачем ИТ-директору знать про СЭД?

Однажды меня позвали прочитать лекции по СЭД для слушателей Школы IT-менеджмента в РАНХиГС. Это челлендж — ну что интересного я могу рассказать ИТ-директорам про самую скучную вещь на свете, каковой на самом деле является документооборот, будь он хоть четырежды электронный и даже, извините, цифровой?

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

Да и вообще, зачем ИТ-директору знать что-то про СЭД? — Такой вопрос реально прозвучал на одном из занятий и пришлось отвечать.

Мы все пользователи СЭД

Во-первых, СЭД — это система, которой придется пользоваться всем сотрудникам, а не только канцелярии. Даже ИТ-директору придется с ней столкнуться как пользователю. Поэтому не нужно отдавать ее выбор на откуп руководству службы ДОУ.

Одна из типичных причин саботажа СЭД как раз и в том, что выбирают систему одни, а работать в ней заставляют других. Кстати, по этой же причине неудобны и многие государственные системы — их разработку заказывают чиновники, а пользоваться ими приходится гражданам, мнения которых никто не спрашивал.

Итак, причина №1 — позаботиться о себе и своих сотрудниках из ИТ-службы, чтобы от выбранной СЭД вас хотя бы не тошнило.

Не испортить ИТ-пейзаж

Разработчики очень хорошо научились «продавать ИТ бизнесу», это касается любых систем, не только СЭД. Они пытаются обойти внутренних айтишнков и договориться с руководством напрямую, поставив ИТ перед фактом, что выбор сделан. Разумное зерно в таком подходе есть — ИТ-служба не может быть экспертом во всех функциональных областях.

Но справедливо и обратное: блещущая функциональностью СЭД под капотом может иметь такие технологии, что ИТ-директор потом сойдет с ума, решая задачи ее интеграции и сопровождения. Иначе говоря, СЭД должна нормально вписываться в ИТ-ландшафт предприятия и быть в тренде — то есть, быть не слишком старой, но и не супер новой. Для этого ИТ-директор должен ориентироваться в текущей ситуации на рынке СЭД. 

Помните фильм «Марсианин» — как они искали дедушку, который разбирался в софте старого марсохода? С некоторыми СЭД можно угодить в похожую ситуацию. Вендор-то будет рад подсадить вас на такую иглу — не имея своих специалистов и доступных кадров на рынке, придется соглашаться на полный аутсорсинг, а это не каждая организация может вынести.

Причина №2 — не создать себе проблем с внедрением и эксплуатацией, не попасть в зависимость от вендора.

Не документооборотом единым

Пожалуй, самое важное. Сегодня прикладные системы проходят процесс «платформизации», то есть превращаются из законченного продукта с богатыми возможностями настройки в инструмент для создания бизнес-решений. Иначе говоря, если ваша СЭД — платформа, то с ее помощью можно решить много разных задач, а если это закрытая система, то так и будете на ней только документы оборачивать.
— Что в этом плохого? Для каждой задачи своя система. Разве нет?

Тут как раз можно вспомнить термин ECM, который у нас воспринимается как синоним СЭД, хотя таковым не является. Так вот, на ECM-платформе документооборот реализуется как частный случай. Кроме того, на этой же платформе можно, построить управление закупками, маркетингом и продажами, техобслуживанием и ремонтами, и т.д. Но все подобные задачи имеют общее функциональное ядро — управление документами и процессами.

А если позволить бизнес-заказчикам выбирать себе «лучшие решения на рынке», то у вас образуется зоопарк из 5-7 ECM. Разработчики ведь не идиоты — они не пишут с нуля, а берут платформы и на них пилят свои продукты.

О, да, все можно интегрировать. Но это хлеб системных интеграторов, а для ИТ-директора это расходы. Короче, если взять правильную ECM-платформу, то канцелярии будет все равно, а вам приятно — параллельно можно будет закрыть кучу других задач, до которых раньше руки не доходили.

Причина №3 — не плодить сущности без нужды, решать похожие задачи одним инструментом, будет логичнее и архитектурно стройнее.

Ставим точку в давнем споре

По ходу обдумывания лекции у меня случился инсайт насчет давнего терминологического спора о СЭД и ECM — чем наш отечественный подход отличается от западно-буржуазного. Помните, сколько копий было сломано? Оказалось, достаточно взглянуть на это в историческом разрезе, чтобы все стало понятно.

Западный подход к управлению неструктурированной информацией эволюционировал — сначала был Records Management, затем Electronic Document Management, далее Enterprise Content Management, Enterprise Information Management, а сейчас, когда ECM умер (по заявлению Gartner), мы движемся в сторону Content Services Platform.

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

Да, наши СЭД тоже технически выросли и тоже стали именовать себя ECM-платформами. Но ментальность осталась прежней. Как это было у Задорнова — «если попросить нашего человека построить дворец, он построит большой барак».

Справедливости ради стоит сказать, что в последние годы ситуация начала меняться — появились молодые системы, не отягощенные двадцатью годами опыта общения исключительно с государственными и корпоративными бюрократами. Им было бы хорошо избавиться от ярлыка «СЭД», который тянет в канцелярское болото.