Я убежден, что нам давно пора пересмотреть сами основы официального документооборота, взяв на вооружение платформы, подобные GitHub. Та же Единая система электронного документооборота (ЕСЭДО), работающая в периметре систем электронного правительства Казахстана, морально устарела.
Моя основная мысль заключается в том, что существующие системы губит их «линейная иерархия». Я постоянно наблюдаю, как работает большинство СЭД (систем электронного документооборота): это просто «эстафетная палочка». Юрист создал проект, передал его на согласование и ждет. Согласующий передал финансисту — и снова все ждут. А если финансист вносит одну правку, документ, по моему опыту, возвращается в самое начало, и весь этот мучительный круг запускается заново. Это неэффективно. Мы теряем драгоценное время не на саму работу, а на бесконечное ожидание этой «передачи».
Решение, которое я вижу, основано на нелинейной, параллельной модели, как в Git и GitHub. По-моему, все должно быть устроено так: у нас есть один «эталон» документа — главная, согласованная версия (назовем ее «main»). Если кому-то нужно внести правки, он не блокирует документ для всех. Вместо этого, он создает свою «ветку» — личную рабочую копию. Я считаю, это ключевой момент: финансист может работать над своей бюджетной частью, юрист — над пунктами ответственности, и все это одновременно. Никто никого не ждет.
Когда юрист, к примеру, заканчивает свою часть, он не просто «сохраняет» файл. Он создает «запрос на слияние» (pull request). По сути, это формальная заявка: «Я, юрист, предлагаю внести вот такие конкретные изменения. Прошу рассмотреть». И вот тут начинается прозрачное согласование. Ответственный руководитель (или группа) видит каждое предлагаемое изменение, может его обсудить, принять или отправить на доработку. Только после утверждения эти правки попадают в «эталон».
Я прекрасно понимаю, что у этого подхода есть сложности. Мы говорим об «официальном» документообороте. Во-первых, я осознаю проблему юридической значимости: как встроить сюда ЭЦП, ведь согласование в СЭД — это юридический акт? Во-вторых, порог вхождения: Git сложен, и нам нужен будет очень простой интерфейс для обычных сотрудников. В-третьих, есть жесткие регламенты, которые порой требуют именно последовательного согласования.
Подытоживая, я твердо верю, что будущее за гибридными системами: с простым, понятным интерфейсом для пользователей, но с мощным «движком» Git под капотом, который обеспечит параллельную работу, прозрачность и будет интегрирован с системами юридической значимости. Существующие линейные системы — это тупик, и нам нужен этот качественный скачок.
Главный барьер здесь не технология, а культура — необходимость сломать мышление «я начальник — ты исполнитель» и перейти к культуре «мы — команда, работаем параллельно».
Про экономический эффект внедрения Git-модели
Это ключевой вопрос. Если отбросить теорию, экономический эффект делится на прямой — тот, что легко считается, и косвенный — который более масштабный, но сложнее предсказуемый. «Прямых» исследований, сравнивающих внедрение, скажем, Documentolog (популярная в Казахстане СЭД) и GitLab «лицом к лицу» по затратам, вы не найдете. Это слишком новая концепция для госсектора. Однако оценку эффективности можно составить, проанализировав типы экономии. Эффективность здесь — это не просто «сэкономили на бумаге», как часто рапортуют при внедрении любой СЭД. Эффективность — это сокращение времени цикла процесса.
Во-первых, рассмотрим прямую экономическую экономию. Это наиболее очевидные статьи расходов, которые сокращаются. Главный пункт здесь — экономия на человеческих ресурсах и фонде оплаты труда. Мы экономим не столько человеко-часы, ведь юрист все равно потратит 3 часа на вычитку, сколько календарное время и «время ожидания».
Представим линейную модель: документ на 5 согласующих. Каждый тратит 1 день на работу. Но из-за очереди задач, совещаний и бюрократии, документ лежит у каждого «на столе» 3 дня, из которых 1 рабочий и 2 дня ожидания. В итоге расчет таков: 5 согласующих умножить на 3 дня на человека — получаем 15 календарных дней на согласование.
Теперь Git-модель: те же 5 согласующих. Они получают задачу одновременно. Самый медленный из них, допустим, финдиректор, так же тратит 1 рабочий день, но «добирается» до задачи за 2 дня ожидания. Расчет уже другой: максимальное время ожидания 3 дня плюс 1 день на «слияние» (merge) и финальное ревью — получаем 4 календарных дня.
Экономический эффект очевиден: процесс ускорился в 3,75 раза. В масштабах Казахстана, где согласование в квазигосударственном секторе (условный «Самрук-Казына») или министерствах может занимать месяцы, сокращение цикла с 30 дней до 8 — это высвобождение колоссального человеческого ресурса, который не «ждет», а занимается следующей задачей.
Сюда же относится экономия на лицензиях и внедрении. Линейная СЭД в Казахстане — это крупные вендорские решения. Затраты включают дорогостоящий консалтинг и настройку, оплату лицензий за каждого пользователя и обязательный годовой контракт на поддержку. В Git-модели же можно использовать бесплатный open-source GitLab на своих серверах или относительно недорогие облачные тарифы. Основные затраты — это не покупка ПО, а обучение и изменение культуры. Первоначальные затраты на ПО и лицензии в Git-модели стремятся к нулю, а совокупная стоимость владения (TCO) в долгосрочной перспективе будет в разы ниже.
Во-вторых, существует косвенная экономическая эффективность. Это эффект «второго порядка», который обычно в разы превышает прямую экономию. Самый мощный мультипликатор здесь — это ускорение «Time-to-Market». Для бизнеса это означает, что если коммерческое предложение или договор согласовывается 4 дня вместо 15, сделка закрывается быстрее, деньги поступают на счет раньше. Для государства, в контексте Казахстана, это еще важнее. Если проект поправок в закон или запуск новой госуслуги проходит согласование в 4 раза быстрее — экономика получает необходимые реформы раньше.
Также снижаются риски и издержки на аудит. В линейной СЭД часто теряется история правок в файлах типа «Версия 4_финал_от ИБ_v2.docx». В Git-модели каждое изменение, каждым автором, каждой буквы — записано в неизменяемый лог. Экономический эффект — нулевая стоимость аудита изменений и мгновенное выявление ответственного за ошибку.
В итоге, можно сделать следующие выводы в контексте Казахстана. Экономика страны во многом зависит от крупного госсектора, страдающего от «линейно-иерархической» бюрократии, где «цена ожидания» максимальна. Казахстан успешно прошел этап «бумага → линейная СЭД», получив экономию в 30-40% за счет бумаги и почты. Эффективность Git-модели — это следующий скачок. Он дает экономию не 30%, а 300-400% по главному ресурсу — времени.