Вредные советы: анти-инструкция по внедрению внутреннего учета компании

Если хочешь ты систему феерично завалить, ты прислушайся к советам, знай потом — кого винить. Руководитель внутренних проектов ALP Group Алексей Орлов делится личной чертовой дюжиной проверенных способов превратить внутренний проект внедрения в нескончаемую головную боль.

Внедрение систем внутреннего учета, в том числе в самих компаниях-интеграторах, является очень важной миссией, поскольку такие системы не только обеспечивают бухгалтерский и управленческий учет в целом, но еще и раскрывают качественные показатели работы каждого проекта, которые в бухучете зачастую просто не видны.

При этом, несмотря на важность внутренних систем, задачи по их созданию и доработке нередко зависают в бэклоге. И это объяснимо: все силы и умы брошены на внешние проекты. В итоге, если на стандартный проект внедрения учетной системы для внешнего заказчика уходит порядка полутора лет, то на внедрение схожего ИТ-решения для внутренних целей уходит примерно вдвое больше времени.

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

Словом, внедрение внутреннего учета — область разработки, особенно подверженная всевозможным факапам. За почти 30-летнюю историю компании, мы столкнулись примерно со всеми ошибками, какие только могут быть. Всё, что могло пойти не так, в какой-то момент… пошло не так. Чтобы пройтись по всем «граблям», предлагаю придерживаться такого списка вредных советов:

1. Не ищите конечного заказчика.

Искать ключевого внутреннего заказчика и собирать с него подробное ТЗ не обязательно — кому-нибудь система да пригодится — откуда-то запрос ведь поступил. Как говорится, если звезды зажигают — значит — это кому-нибудь нужно. А если менеджеры компании поспорили насчет необходимости и последовательности внедрения — не трогайте их, пусть сами разберутся.

2. Сразу делайте систему «на вырост».

Решение должно быть универсальным, всеобъемлющим и многофункциональным. Старайтесь охватить как можно больше блоков — в системе должно быть всё. Если для текущих задач пока что хватит, например, кастомизированной «1С:БУХ», беритесь сразу за внедрение «1С:ERP», чтоб наверняка!

3. Беспрекословно выполняйте ровно то, что вам говорят, даже если это противоречит логике и бюджету проекта.

Если, например, кто-то требует, чтобы в системе строился определенный отчет, но при этом не выделяет адекватный задаче бюджет, то просто сделайте ему этот отчет. Если при этом в итоговом отчете будет куча недоработок и всё будет как-то не так — что ж, это не ваша проблема. Вы не виноваты, что на многих проектах соблюдается другой вредный совет — по выстраиванию обратно пропорциональной зависимости между желаниями и финансовыми возможностями.

4. Не волнуйтесь насчет безопасности — на внутренних проектах она не важна.

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

5. Не тратьте время на составление реестров требуемых данных.

Раз управленческий учет ведется, значит, данные где-то есть. Приступайте к разработке новой системы незамедлительно. Если по ходу дела, например, выяснится, что по нескольким компаниям в группе ведется не совсем правильный и совсем не единообразный учет сразу в нескольких базах данных, то вы разберетесь с этим когда придет время. После закрытия первого периода исправление перекосов в учете всегда можно дополнительно согласовать и внести в план-график.

6. Помните, что вы не ясновидящий и не обязаны смотреть в будущее.

Не занимайтесь прогнозированием того, как дальше будет развиваться учет в компании, и не думайте о будущих обновлениях ПО от вендора. Если вы не заложите в систему возможность корректного и быстрого обновления функционала, ничего страшного не случится — напротив, вы сэкономите время, которое иначе ушло бы на регулярную переустановку софта.

7. Учитывайте пожелания всех отделов.

Помните, что все требования по доработке системы от всех отделов одинаково ценны, даже если определенный отдел пользуется системой буквально раз в год. Доработка функционала должна быть бесконтрольной и бесконечной. Только хаос, только хардкор.

8. Не нужно морально готовить линейный персонал к переходу на новую систему.

Сотрудники не хрустальные, они не развалятся. Как начальник сказал — так и будет. Не ваша забота ходить и объяснять каждому, что автоматизация неизбежна и в новой системе им же потом и работать.

9. Не обезличивайте данные — пусть все секреты вылезут наружу.

Тайны — это нехорошо. Вскрывая их, вы делаете благое дело.

10. Не теряйте времени даром — сразу начинайте знакомить пользователей с системой.

Обучение нужно запускать чем раньше, тем лучше. В идеале — еще в момент разработки решения. Нет никаких шансов, что через пару лет сотрудники забудут про устройство системы, которую вы им однажды так красиво описали.

11. Оставьте текстовые обучающие инструкции в прошлом.

Как известно, у современного человека «клиповое» мышление, так что видео всегда будет предпочтительнее текста. Подготовьте пятичасовые непроматываемые видеоинструкции для сотрудников — они скажут вам «Спасибо!».

12. Еще лучше — не делайте никаких инструкций вообще.

Кому надо — тот и так разберется. В конце концов, любая современная ИТ-система интуитивно понятна. Если возникают вопросы, значит, у кого-то барахлит интуиция. Вы не обязаны тратить время на написание инструкций по каждому процессу, блоку и возможному чиху в системе.

13. Не следите за моральным состоянием ваших разработчиков.

Их психическое здоровье — не ваша проблема. Если выгорят — это повод с ними распрощаться.

За почти 30 лет работы мы в том или ином объеме успели опробовать все вредные советы на себе на всех этапах внутренних проектов — от проектирования до обучения. Будучи руководителем внутренних проектов в разных компаниях, я за свою карьеру сталкивался с ситуациями, когда разрабатываемые по 3–4 года системы ложились на полку по причине своей чрезмерной сложности, когда директора подразделений были против системы, когда буквально на первой минуте обучения все производственники вставали и молча выходили из кабинета, потому что система была им не нужна, и когда переутомившиеся разработчики засыпали прямо на совещании или в офисе за компьютером в разгар рабочего дня.

Конечно же, описанные ошибки исправлялись и давали колоссальный опыт, но всё это требовало привлечения дополнительных ресурсов и порой затягивало наступление счастливого финала. Все мы знаем, что не ошибается только тот, кто ничего не делает. Надеюсь, что наши вредные советы помогут вам избежать схожих проблем и позволят найти короткий и правильный путь к успешным внедрениям внутренних проектов.