По щучьему веленью, по моему хотенью: правильное ТЗ — залог успеха проекта

Руководитель корпоративных практик ALP Group Александр Казеннов объясняет, как составить ТЗ таким образом, чтобы ваши ожидания совпали с реальностью, и вы получили от интегратора ровно ту систему, которую хотели.

В идеальном мире заказчик приходит к интегратору с готовым ТЗ и четким представлением о том, что и в каком виде он хочет получить от готовой ERP-системы. Но реальность далека от этой утопии. На практике, множество заказов звучит как в классическом сказочном сюжете: «Пойди туда — не знаю куда, принеси то — не знаю что». Так делать не нужно.

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

Определить цели автоматизации можно с помощью таких базовых методик целеполагания, как S.M.A.R.T. или G.R.O.W. На всякий случай напомню, что аббревиатура S.M.A.R.T. обычно расшифровывается как конкретная (specific), измеримая (measurable), достижимая (attainable), актуальная (relevant) и ограниченная по времени (time-bound) цель. В свою очередь, модель целеполагания G.R.O.W. представляет собой матрицу из цели (goal), реальности (reality), препятствий (obstacles) или вариантов (options) и плана действий (way forward).

Разобравшись с общей концепцией информационной системы, можно переходить к более приземленным вопросам:

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

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

Самый лучший (хоть и почти не встречающийся в природе) вариант — это прийти к интегратору уже с детальным ТЗ и всеми методологическими документами, а не обследовать собственный бизнес с ним за руку или додумывать на ходу. По опыту скажу, что заказчики очень часто вспоминают про важные детали, возвращаются с обещанным ответом или меняют требования уже в разгар разработки (например, внезапно решают, что хотят рассчитывать себестоимость не по методу ФИФО, а по методу средневзвешенной стоимости). Одно дело, когда требования уточняются в ходе проекта, и совсем другое — когда у проекта кардинально меняется вектор.

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

Может ли компания-интегратор помочь в составлении ТЗ? И да и нет. У большинства интеграторов есть заготовленная анкета с вопросами о целях, задачах и ресурсах для автоматизации и/или примеры описания функционально-технических требований. Эти шаблоны позволяют понять базовый пул проблем, который интересует подрядчика. Но нельзя забывать, что любая универсальная анкета, не созданная специально под ваш бизнес, априори не может учитывать всей его специфики.

Первичное анкетирование — хороший способ показать подрядчику, в какой проект он входит, но никак не замена полноценного ТЗ. Дальнейший успех проекта внедрения во многом зависит от того, как и какую информацию заказчик будет выдавать интегратору. Как теперь знает любой человек, хоть раз поигравший с чат-ботами на основе нейросетей, результат напрямую зависит от того, как сформулировать свой запрос (промпт).

Озвучив абстрактный запрос («Сделайте мне красиво!»), вы рискуете столкнуться с тем, что подрядчик сделает всё так, как поймет (а не так, как вы себе это представили). И тогда получится как в печальном анекдоте: «— Золотая рыбка, хочу, чтобы у меня всё было! — Пожалуйста. У тебя всё было». Не уделив должного времени на составление ТЗ (или хотя бы четких требований), не стоит год спустя удивляться, что на выходе получилась какая-то «не такая» система. Скорее всего, это ровно та система, какую вы описали: цифровое решение, которое справляется с базовой автоматизацией процессов и не учитывает всё то, что отличает ваш бизнес от всех остальных.