Кажется, что крупные компании уж точно не страдают от проблем с согласованием договоров, соглашений, отчетов, положений. А вот и нет — даже у таких компаний эти процессы зачастую недостаточно автоматизированы. В этой статье я хочу поделиться своим видением проблемы, а также расскажу о варианте ее решения на примере кейса с поставщиком продуктов в нефтехимии «АВК». Всех, кто беспокоится о том, что документы «зависают», приглашаю под кат.
«Главная причина — это боль»
Меня зовут Кирилл Гончаров, я занимаюсь цифровой трансформацией (и в частности разработкой ERP) в BusinessPad. И как раз недавно у нас был показательный кейс по оптимизации внутреннего документооборота в компании «АВК». Самое интересное, что ничего прямо очень интересного в этом кейсе не было. Если взглянуть со стороны, компания просто расширила использование механик BPMN, которые могут прятаться внутри ERP-продукта, на внутренние согласования документов. Но при этом сама ситуация вызвала у меня четкое ощущение дежавю. Ведь многие организации сталкиваются с тем же самым, потому что у всех возникают почти одни и те же вопросы:
Еще не согласовал? Очень часто нужный документ зависает у очередного сотрудника и может быть согласован на несколько дней позднее, потому что человек не увидел уведомление, забыл про документ, отвлекся, ушел в отпуск, ему не нравится тот, кто отправил документ, «ему за это не доплачивают» и так далее.
А у кого документ? Иногда бывает вообще непонятно, на каком этапе находится документ, кто должен сейчас его согласовать: Петров говорит, что уже внес правки и отправил дальше, Сидоров — что уже дал ответ, а Иванов утверждает, что ничего не видел, и ему ничего не присылали. Где же застрял документ?
И вообще, идет ли работа? Далеко не всегда согласование — простой и прозрачный процесс. Я нередко сталкиваюсь с тем, что инициатор прописывает только название этапа: «Согласование». А внутри него может происходить любая чехарда, в том числе совершенно нелогичная. Практика показывает, что без единых стандартов почти каждый исполнитель изобретает свою процедуру.
Это точно последняя версия? Пользователи стараются маркировать документы, отправлять друг другу версии с датами и пометками, кто согласовал очередную итерацию. Но в длинных цепочках добрую половину шагов, как правило, приходится проходить заново, потому что кто-то переслал «устаревший документ», все-таки не выделил изменения, ошибся при отправке и так далее.
Учли ли вы мои требования? Как следствие предыдущего пункта, уже на финальном этапе может выясниться, что важные, но немотивированные правки юриста или замечания замначальника отдела в документе никто не учел. Это происходит, когда инициатор изменений не объясняет причины своих правок. Начальник требует: «Давайте сократим сроки оплаты». Юрист отвечает: «Эти сроки оплаты и так минимальны», и он тоже прав — ведь он не в курсе, что сокращение сроков утвердили на уровне стейкхолдеров.
Когда же гендиректор подпишет документ? Это огромная боль многих компаний. При стандартной непрозрачной схеме гендир должен получить утверждающий лист или его аналог, на котором стоят подписи всех ответственных. Причем этот лист должен застать его в рабочем кабинете, когда у него есть хотя бы две минуты свободного времени. При этом гендир может легко усомниться в том, что документ выверен, а еще задуматься о последствиях подписания. А малейшая тень сомнения может привести к желанию отложить документ. Как следствие, процесс финального подписания затягивается. Впрочем, и без этого в «приемной» начальства накапливаются кипы документов, которые нужно подписать, и времени в них вникать попросту нет. Как шутит мой знакомый: «У нас в стране сложилась практика подписания договоров не глядя, а мелкий шрифт читают уже в суде»
Конечно, кажется, что эта проблема исключительно менеджеров разных мастей. Но в IT-разработке мы видим схожие проблемы. Вот сравните:
Когда уже пройдет код-ревью? Очень часто фикс зависает в ревью на несколько дней. Причин может быть много. Например, ревьюер забывает про пулл-реквест, уходит в отпуск или решает, что это «не его зона ответственности». Бывает, что ответственный откладывает проверку, потому что «там же всего пару строк» (в духе: «накоплю-ка я себе пачку таких запросов и вечером следующего четверга все их обработаю»), или наоборот — придется писать много комментариев к коду junior-разработчика (а он не учится, да и вообще за правку чужого кода путем его переписывания не доплачивают). А еще и сам разработчик может не увидеть комментарии в MR или просто проигнорировать их (да, такое бывает).
Где сейчас мои изменения? Иногда вообще непонятно, в каком состоянии код. Один разработчик уверяет, что уже замерджил фикс в dev, а другой настаивает на том, что баг все еще воспроизводится. Тимлид при этом может вообще не знать, что изменения попали в прод, потому что пайплайн сработал автоматически, и кажется, что у нас все Окей. Конечно, это можно решить, настроив процесс взаимодействия, но часто хочется быстрее все скинуть в продакшн, «почистить доску от тасок» и пойти выгуливать собаку... ведь не все CI/CD-процессы прозрачны. В логах пайплайна может быть ошибка, но никто не мониторит уведомления, или например, тесты падают неделю, но все делают вид, что это «некритично». Вместо четких этапов (build → test → deploy) в проекте могут быть хаотичные сценарии доставки кода в прод, которые каждый поддерживает как умеет. И более того, этот «каждый» будет в грудь бить кулаком, что так правильно и вообще ему так удобнее и у него на локалке все работает.
Это точно финальный код? Все манифесты для разработчиков призывают писать осмысленные сообщения и тегировать релизы (оставляя после себя «paper tale» — хвостик из документации по коммиту). На практике все делают кто во что горазд: могут залить изменения прямо в мастер, минуя ветку (и правда, зачем нам ветки, нас же тут три разработчика всего, кто этой фичей занимается и мы все рядом сидим, да?), или в прод улетает старая версия, потому что забыли переключиться с feature-ветки (у нас у самих так было несколько раз — можете смеяться). А вместо rebase команда делает мержи из мастер-ветки в feature-ветку, и история коммитов превращается в нечитаемую кашу, потому что rebase (и другие редкие команды) — это СТРАШНО (я не шучу — это мне реальный разработчик так мотивировал свои MR-ы).
Когда же это попадет в прод? Финальный деплой — всегда лотерея. Ответственный за релиз может быть в отпуске, а безупречно работавший скрипт может сломаться. Пайплайн зависает на 93%, но никто не решается его отменить. Или вообще никто на следит за его прохождением (а что? вечером запустил, утром посмотрим, что там по результатам). На финальном этапе вдруг выясняется, что критичный баг-фикс потерялся где-то при вливании веток; тестировщики проверили не ту сборку, тесты упали в очередной раз, не хватило ресурсов для git-раннеров на VDS-ке, слетел сертификат… и так далее…
Короче, видим все те же организационные проблемы, но уже в контексте разработки и DevOps. Все те же невнимательность, непонимание процессов, отсутствие стандартов и вечная надежда на «авось» и «пронесет».
Конечно, решать такие задачи в IT компании вроде как уже должны были бы научиться, однако на деле не всё так однозначно. Впрочем, это тема для отдельной беседы, а мы давайте вернемся к документообороту…
Как решить эти вопросы
Реализовать задачу по автоматизации документооборота можно в любой ERP-системе, да даже в Excel. Я же расскажу, как это сделали в BusinessPad.
В ходе обсуждения задачи для «АВК» (а коллеги давно обдумывали решение проблемы автоматизации внутреннего документооборота, потому что согласование договоров иногда занимало неоправданно много времени), мы получили следующие запросы:
Четко регламентировать время пребывания документа у каждого сотрудника;
Предусмотреть разные маршруты для разных типов документов;
Запретить вносить правки в документ «после» его согласования;
Упорядочить работу с версиями;
Дать генеральному мобильное приложение и установить нормативный срок финальных решений по документам.
Чтобы все это сделать, мы сначала нарисовали модель работы с документами в формате BPMN.
Заказчику предложили достаточно гибкую модель, в которой предусмотрели различные ветви процессов, этапы исполнения, а также требования к заполнению элементов. И по итогам ее обсуждения принятую схему реализовали на базе конструктора BusinessPad.
Особенности
Чтобы «подогнать» документооборот под привычный режим работы сотрудников, нам пришлось зафиксировать несколько форматов, которые раньше были недостаточно стандартизированы.
Мы выработали единый процесс, в котором стандартные документы, например, идущие с тендерных площадок или типовые документы, не требующие широкого спектра согласований, идут одним треком, а нестандартные — другим.
Четко регламентировали контроль версий, чтобы исключить путаницу, а также возможные подмены финальных версий договоров.
Настройка ветвей шлюза
Ограничили права на изменения документов и при передаче на следующий этап (или наоборот, на доработку на шаг назад), утвердили форму объяснения причин правок (оставили возможность отметить «принято без изменений»), а также указание даты передачи.
Установили на телефон генерального директора мобильное приложение (разумеется, с надежной аутентификацией и защитой от НСД), в которое автоматически подтягиваются документы, собравшие все необходимые подписи. При этом он может просмотреть всю историю подготовки документа, финальные объяснения того, как принимались решения по каждому пункту, и пр.
Как результат, гендиру больше не нужно читать договор на 100500 страниц, связываться с отдельными сотрудниками, выяснять важность изменений в документе и пр.
Альтернативы?
Нет, наверное, можно было бы создать проектный офис по регламентации процессов, который полгода выпускал бы регламент. Дальше он поэтапно бы его внедрял и тратил немало времени и ресурсов на обучение сотрудников, а еще сил на преодоление сопротивления коллектива. Но практика показывает, что люди вполне адаптируются к стандартизированным процессам, которые помогают им не уходить в лишнее «творчество» при согласовании документов. К тому же мы заранее предусмотрели возможность создавать новые действия на случай нестандартных условий.
В итоге переезд на новые «рельсы» документооборота занял около четырех месяцев. Это при том, что ничего не нужно было программировать — бизнес-процесс собирался из модулей в конструкторе. Зато после его завершения общая скорость работы над документами и их согласования увеличилась на 20–25% (по итогам первых тестов). Учитывая количество договоров «АВК» и объем человеческих ресурсов, затрачиваемых на это, результат сам по себе внушительный, хотя процесс, казалось бы, достаточно простой.
Результаты автоматизации документооборота в «АВК»:
Прозрачность — самый главный результат. Все движения по процессу согласования теперь видны;
Отсутствие ошибок. Новое исполнение процессов исключает ошибки, которые могли появляться и накапливаться до автоматизации. Это уже продемонстрировали десятки согласований;
Нормативный срок исполнения процесса сократился не на много, примерно на 20%. Но у этапов согласования появилась нормативная длительность, временные стандарты. А значит, уже на старте ясно, сколько времени задача может находиться на этапе исполнения.
Реестр договоров стал единым: все документы находятся в одном месте, а не в разных подразделениях, как было раньше. А значит, все сотрудники видят одну и ту же версию договора;
Упростилось подписание листа согласования. Сейчас генеральный директор в мобильном приложении видит все договоры, комментарии к ним, даты, степень рисков и другие нюансы;
Появилась закрепленная стандартная процедура срочного согласования договоров.
3. Разбор полетов: почему в этом кейсе все обыденно
Во время работы с «АВК» мы столкнулись с абсолютно стандартной задачей и в очередной раз убедились, что наше дизайн-решение самое оптимальное. Разобранный кейс неуникальный, и в этом его особенность.
Казалось бы, все современные компании работают с различными системами автоматизации, в которых есть опции документооборота. Но почему такие вопросы остаются нерешенными? Я, конечно, не могу говорить за всех, но на нашей практике в большинстве случаев люди не хотят адаптировать процессы под лекала, предусмотренные в готовых системах, или пытаются работать так, как им было привычно на прошлых местах работы. Кстати, даже в «АВК», где уже давно используют BusinessPad, нашлись люди, которые предлагали автоматизировать документооборот в более известных продуктах, даже запрашивали коммерческие предложения у других интеграторов.
Но самое интересное, что подобный процесс сложно сдвинуть с мертвой точки, когда людей ставят перед выбором — адаптироваться под какие-то стандартные процессы или остаться с привычными согласованиями в электронной почте. А, может быть, даже продолжать работать в режиме согласования в курилке или за обедом (и такое тоже бывает). Подобные процессы только чудом не приводят к потерям и неверным решениям.
Даже если компания доверяет сотрудникам, и в целом все работает хорошо, здесь работает принцип: «Сократ мне друг, но истина дороже». То есть руководитель хочет сделать бизнес-процессы прозрачными и надежными, избавиться от «области тьмы».
Почему наш кейс удался? Мы пришли к клиенту со своей экспертизой и сразу предложили наилучший вариант для подобной ситуации, а именно: сделали вариантное предложение, то есть выложили на стол готовый стартовый пакет решений разного уровня зрелости. Так клиент получил наглядное представление того, что он хочет. То есть мы на страте предугадали выбор заказчика, но сказали, что согласовывать документы можно условно по-простому, по-среднему и по-сложному. Люди в силу психологии обычно не хотят выбирать крайние варианты: просто — «как-то несерьезно, мы же солидная компания», а сложно — «возникнет много проблем». В итоге останавливаются на среднем, считая, что такое решение даст неплохой результат. И часто оказывается, что этот средний вариант — уже лучше, чем сложившаяся практика. Иногда в разы.
Реализовать решение можно было «часа за два», но процесс занял почти четыре месяца, что очень много. Сроки затянула не слабость IT-решения, а трудности в согласовании внутреннего решения среди сотрудников на стороне клиента. Нам пришлось многое объяснять, доказывать — и часто по несколько раз одним и тем же людям. Этот процесс можно сравнить со свиданиями. На отношения между людьми влияют общие цели, совместно проведенное время и базовая симпатия. Но если не ходить на свидания, любовь не найдешь. Так и здесь: если не пушить в мастер, фичи не смержаются (а у вас как кстати говорят - смержить, замержить, выполнить реквест?).
Люди, которые занимаются бизнесом, в отличие от разработчиков, не могут детально погружаться в аналитику, программирование. У них просто нет на это времени. Вдобавок, они считают IT-сферу чем-то магическим, поэтому быстро ставят задачу и рассчитывают на превосходный результат.
Когда вендор предлагает экспертное решение, то нередко люди из бизнеса восхищаются его широтой и оригинальностью. При этом многие из них по-прежнему опираются на свой личный опыт или частные мнения знакомых из отрасли. И как часто бывает, придуманные ими решения обычно нацелены не на повышение качества процессов, а на облегчение жизни конкретных людей (меньше напрягать мозг, меньше уделять времени), тогда как вендор независим и борется «за все хорошее против всего плохого». Хотя он так же может бороться и за то, чтобы получить как можно больше денег, пока идёт на пути к светлому будущему - это тоже распространенная практика, увы.
Стандартизация процессов с высоким уровнем зрелости подразумевает, что любой Junior/Middle/Senior-сотрудник выполняет задачу оперативно, условно за три/два/один день с вероятностью ошибки не более 30%/20%/10%. На деле же люди предпочитают растягивать выполнение задачи на недели, а то и месяцы, чтобы продемонстрировать свою важность для бизнеса. То есть, на самом деле работник может тратить на выполнение задач около 13% рабочего времени, а закладывать на эту деятельность все 100% своего «капасити». К сожалению, мало кто из сотрудников признает, что в течение рабочего дня у него есть свободное время на дополнительные задачи. В реальности случается и то, что Senior-сотрудник решает задачи уровня Junior, имитируя при этом бурную деятельность. Или же опытный сотрудник продает свои услуги сразу нескольким компаниям и работает на каждую вполсилы (мы не поощряем такую практику).
Крайне важно, чтобы бизнес понимал, какие сотрудники загружены эффективно, а какие нет, и регулировал нагрузку. Например, в компании могут быть два юриста для подстраховки (на случай, если один заболеет или уйдет в отпуск). Тогда в обычное время этих двух специалистов нужно занимать чем-то полезным для бизнеса и в рамках их профессиональной деятельности: писать обзоры, вести колонку в соцсети компании по профильной тематике, возможно, выступать на конференциях. Кто-то может сказать: дашь сотруднику развивать личный бренд, и его в итоге заметят и переманят. На самом деле, заинтересовать кого-то на рынке не так легко — одного выступления на конференции или поста в социальных сетях недостаточно. Да и не так просто попасть на конференцию спикером, как кажется, особенно юристу…
Человек по своей природе склонен выбирать задачи, которые приносят ему быстрые победы, а также не любит выполнять регулярные действия по одной и той же схеме. В итоге он фантазирует и просит создать какое-то индивидуальное IT-решение. Но нужно понимать, что разработчики ПО не придумывают каждый раз новые языки программирования, SOLID, ООП для решения стандартных задач, так как они уже определены. В связи с этим я считаю, что самый верный путь — на старте предлагать экспертное решение хорошего уровня, а не просто слепо исполнять запросы клиента. Бездумное следование желаниям заказчика — главная ошибка разработчиков и автоматизаторов всех мастей.
Утилизация рабочего времени свойственна и компаниям, которые занимаются аутсорсингом персонала, да и внутренние сотрудники порой этим грешат. Ведь задачи приходят редко, а кушать хочется всегда, поэтому люди берут и множат неэффективность собственных процессов. Аутсорс часто на старте просит «миллион денег», но через месяц-два проводит переоценку и просит уже «пять миллионов денег». Вопрос: почему цена меняется в процессе? Ответ: у них нет клиента, который бы платил условно по «пять миллионов» в месяц, поэтому они растягивают задачи на полгода вперед, чтобы обеспечить себя работой и стабильностью. При этом в таких компаниях понимают: если клиент уже влез в разработку, то отказаться от нее будет дороже. Кстати, такое положение дел характерно не только для IT, но и для строительства, сферы ремонта, консалтинга и т.д. Исключение — аутсорс-бухгалтерия, где высокая конкуренция, и выживают только те, кто максимально оптимизировал свои процессы.
Что вынести в лайфхаки?
Если к вам приходит заказчик с подобной задачей, не поленитесь сделать домашнюю работу — два-три варианта решений в своей системе. То есть не нужно приходить к клиенту только с успешными кейсами и рассказывать, какие вы молодцы. Лучше презентовать упрощенное, среднее и нагруженное решения задачи. Так вы продемонстрируете глубину своего подхода к работе.
Не стоит воспринимать заказчика как бога. Это живые люди, которые могут чего-то не знать, в чем-то сомневаться. Поэтому велика вероятность, что в какой-то момент вам, как поставщику ПО, придется взять на себя ответственность и предложить авторское экспертное решение.
Регулярно проводите встречи с клиентом и следуйте графику. Методичность и последовательность очень важны в нашей работе. Ритм очень помогает, главное не загонять лошадей.
Нужно как можно быстрее отдать клиенту пилотный вариант и протестировать его в работе. Потому что обратная связь на встречах может кардинально отличаться от фидбека после реального использования системы.
Если в системе что-то не работает или вообще отсутствует функционал, не нужно бояться сказать об этом заказчику. Даже если за этим последует отказ от сотрудничества, вы получите время на поиск более подходящего варианта, либо, если идти больше некуда — лучше снизить цену, чем ждать журавля с IT небес.
Всё предусмотреть невозможно. Не бойтесь мечтать.
