{"id":9454,"title":"\u041a\u0430\u043a \u0441\u0442\u043e\u043b\u044f\u0440\u044b \u0438\u0437 \u0420\u044f\u0437\u0430\u043d\u0438 \u0437\u0430\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u044e\u0442 \u043d\u0430 \u0434\u0435\u0440\u0435\u0432\u044f\u043d\u043d\u044b\u0445 \u0434\u0438\u043d\u043e\u0437\u0430\u0432\u0440\u0430\u0445","url":"\/redirect?component=advertising&id=9454&url=https:\/\/vc.ru\/pochta\/328045-kak-stolyarnaya-masterskaya-iz-ryazani-nachala-prodavat-tovary-po-vsemu-miru&placeBit=1&hash=2a5fe1185750debf6eff79c9510d5a82ba810f16be799f12f89083789a4f685f","isPaidAndBannersEnabled":false}

Почему «без ТЗ результат ХЗ». Разбираем на примере CRM-систем

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

К нам пришла компания с внедренной CRM-системой. Компания клиента давно существует на рынке. Несмотря на то, что ее процессы не описаны «на бумаге» — они работают довольно хорошо, но не системно.

Предыдущий интегратор никак не проработал его процессы. Они отрисовали процессы на верхнем уровне. Условно вот пришел лид: он либо успешен либо нет, если успешен, то вот продажу заводим. Cказали, что детальнее разберемся «по пути».

Кроме верхнеуровневой схемы процессов клиенту не сделали никакого ТЗ. По BPMN этот уровень называется согласовательным, ниже развернем, какие еще бывают.

Внутренности статьи

Как обычно заказывают внедрение системы

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

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

Клиент со своей стороны хочет быстрее получить КП, чтобы показать руководству свою эффективность.

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

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

Пример формулирования запроса клиента в формате: интеграция с сервисами №1, №2, №3. Скажите, стоимость внедрения

Интеграторы, чтобы не терять клиентов делают предложение наобум, лишь бы вписаться в проект и заработать денег.

В итоге они начинают делать проект вместе. Но в моменте, когда часы запланированные на проект уже закончились, не реализована еще даже половина проекта. Просто потому что оценка была «на отвали».

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

Иногда разработчики предлагают работать без оценки, по часам. Еще это называют Time&Material. Работает это так: есть согласованная ставка — прилетает задача — делаем — сколько потратили, столько потратили.

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

Почему интеграторы делают то, что не поможет клиенту

Проблема в том, что на нашем рынке много кто решает задачи на «пофиг». Например, крупный производственный холдинг приходит ставить себе CRM, чтобы управлять закупками. А на самом деле для этого нужна SRM.

Часто интеграторы не пытаются узнать, зачем клиент хочет сделать ту или иную задачу: что решает проект, как он повлияет на финансы компании?

Большинство подрядчиков работают лишь бы сдать проект и не задумываются о бизнес-целях клиента. По честному — они просто хотят заработать денег.

Разберем типовые проблемы, которые возникают из-за отсутствия ТЗ.

Проблема № 1 — Недополученная прибыль

Когда бизнес работает давно, и ему нужно внедрить систему — нет права на ошибку. Пару лет назад мы делали CRM, и параллельно клиент у себя делал систему учета (ERP). Но из-за того, что процессы не были формализованы, не получилось их оцифровать.

Когда запустили ERP-систему — она заблокировала работу из-за отсутствия нужных сценариев. Отгрузки встали.

Запуск проектов внедрения без ТЗ — это удел стартапов. В стабильном устоявшемся бизнесе — это способ потерять деньги.

Проблема № 2 — Бесконечный цикл внедрения

Это очень опасно, как для клиента, так и для интегратора. Расскажем на нашем примере проекта по фиксированной стоимости.

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

Проект растянулся на 2 года по времени и ушел в бесконечный цикл правок. По итогу мы поняли, что мы накосячили с тем, что не прописали четкое ТЗ в самом начале, и решили прекратить работу по проекту.

4 млн рублей
Сумма наших убытков из-за того, что проект ушел в бесконечный цикл правок. С учетом возврата денег за проект и лицензирование.

Проблема № 3 — Ожидания ≠ результат

Заказчик отдает задачу в работу → мы делаем, и потом ожидания не сходятся. В такой порочный круг попадает много компаний.

С одной стороны — клиент в постоянной «запаре» и не может четко понять, что именно ему нужно сделать. С другой — интегратор, который делает все четко по словам клиента и не понимает, почему каждый раз приходится все переделывать.

Чтобы этого не допускать нужно помогать клиенту в формализации его задач и четко прописывать их в ТЗ. В потоке операционных задач не все могут посмотреть на процессы со стороны и понять главные цели и требования.

ТЗ — защищает интересы интегратора при работе и поддерживает его маржинальность. Но не надо упираться в этот документ при любом разногласии с клиентом. Нужно балансировать между ТЗ и хорошими взаимоотношениями.

Например, если доработка занимает 1 час времени — то не нужно ругаться из-за этого с клиентом. И уж тем более выставлять доп.счета — лучше преподнесите это, как бонус.

Главная задача ТЗ — сформулировать у клиента четкое понимание того, что он получит в конечном итоге.

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

Проблема № 4 — Непонятная стоимость проекта

Когда не зафиксированы требования — стоимость проекта может расти бесконечно. Чем четче вы представляете конечный результат, тем меньше денег вы потратите и быстрее к нему придете.

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

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

Но проблем достаточно, давайте разберемся, как их избежать.

Этап № 0. Бизнес-цели

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

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

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

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

Важно сделать изменения в первый год, чтобы в оставшиеся 4 года обеспечивать этот рост. А возможно после первого года приоритеты изменятся и задачи поменяются.

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

Этап № 1. Сроки и бюджеты

Возвращаясь к нашему примеру — сроки мы уже определили (1 год).

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

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

Представим, что наш потенциал роста — 15 млн. Значит бюджет проекта может составить 5 млн. Но вообще, ваши финансисты подскажут подробнее.

Этап № 2. Требования

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

Пример функциональных требований:

  • система должна прогнозировать продажи на основании текущих данных из воронки
  • у системы должен быть портал самообслуживания для клиентов
  • система должна поддерживать возможность работы нескольких менеджеров с одним контрагентом (несколько ответственных)
  • система должна поддерживать контроль выполнения плановых показателей на каждом этапе воронки: количество звонков, количество КП, количество продаж

Нефункциональные требования — это те требования, которые не отражает прямой функционал системы. Например:

  • Поддержка системы 24/7;
  • Коробочное или облачное решение;
  • Брендированный корпоративный портал;
  • Минимальная скорость интернета для работы системы.

Этап № 3. Ролевые модели, объекты системы и данные

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

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

При использовании ролевой политики управление доступом осуществляется в две стадии:

  • Для каждой роли указывается набор полномочий, представляющий набор прав доступа к объекту.
  • Каждому пользователю назначается список доступных ему ролей.

Ролевая модель — описание полномочий сотрудников в системе. Это важно прописать в ТЗ, чтобы заранее понимать функционал пользователей системы и количество уровней доступа.

Пример ролевой модели руководителя отдела

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

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

Упрощенный пример описания объектов системы
Пример описания данных системы

Отдельно еще важно упомянуть про миграцию данных. Нужно описать процесс перехода информации из текущей системы в будущую: из какой системы в какую мигрируем и какую глубину данных (за год или за последние 10 лет) мы забираем.

Далее составляем карты маппинга — старая система → новая система

Этап № 4. Моделирование процессов «как есть»

Это очень важный этап. В нем важно сделать графическое и текстовое описание процессов того, как именно сейчас работают сотрудники.

Зачем это нужно

  • Наглядное описание текущего состояния процессов;
  • Формирования у всех единого представления о текущих процессах.
  • Получение материалов для объективного управления процессами:
    – Поиска узких мест;
    – Разработки планов по оптимизации процессов;
  • Составление плана по разработке и внедрению изменений, чтобы перейти от текущей ситуации к той, к которой хотим прийти.

Мы описываем процессы с использованием BPMN, но можно использовать и простые блок-схемы. Обычно выделяют 3 уровня моделирования процессов:

  • согласовательный;
  • аналитический;
  • исполняемый.

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

Согласовательный уровень — это уровень для руководства, которое заинтересовано в улучшении процесса. Как правило, руководителям интересны: результаты; основные задачи; исполнители и KPI процесса. Тут схема должна быть максимально простой и понятной.

Пример нотации согласовательного уровня Библиотека примеров BPMN

Аналитический уровень. Нужен для непосредственных участников процесса и аналитика. Схема такого уровня может быть ежедневной инструкцией. Для аналитиков из такой схемы интересны:

  • логичность процесса в целом;
  • разделение задач между системами и пользователями;
  • потенциальная возможность улучшения процесса за счёт оптимизации или автоматизации.

Пример нотации аналитического уровня

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

  • данные процесса;
  • группы и роли;
  • бизнес-правила;
  • пользовательский интерфейс;
  • KPI;
  • скрипты и сервисные задачи.

Этап № 5. Моделирование процессов «как должно быть»

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

Зачем нужно

  • Наглядное понимание работы нового процесса;
  • Формулирование дополнительных требований к системе на основании требуемого состояния процессов;
  • Улучшение процессов за счет оптимизации и устранения узких мест.
на основании этой схемы мы описываем само ТЗ и планы перехода

Этап № 6. Точки интеграции

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

  • Детально проработать способы интеграции с необходимыми сервисами и предусмотреть все риски;
  • Подготовить «контракты интеграции» — какие данные, в каком формате передаем или получаем;
  • Найти и устранить узкие места при интеграции или выработать обходные решение;
  • Обеспечить требования по информационной безопасности.
Пример схемы точек интеграции
Пример схемы точек интеграции

Итоговое ТЗ

По итогу все этапы могут занять от 10 до 30 дней, и больше, все зависит от количества процессов, интеграций и формализованности текущих процессов. В любом случае, не пренебрегайте написанием ТЗ, ведь чем лучше вы подготовитесь на этом этапе, тем качественнее проект у вас получится.

Если расписать все эти этапы, то получится документ на 20-30 страниц А4. Для примера — можете посмотреть пример такого ТЗ на нашем сайте.

Читайте другие наши статьи

0
81 комментарий
Популярные
По порядку
Написать комментарий...
Alexander Shirokov

Не так оно всё радужно, как написано) Был участником и свидетелем внедрения множества систем в том числе по описанной методологии и вот что не так (применимо для среднего и крупного бизнеса, в мелком может быть иначе, не сталкивался).
1. Наличие ТЗ не слишком сильно влияет на успех самого внедрения. В плюс-минус большом проекте ваш документ будут читать несколько человек и каждый поймёт его по своему. На десятом цикле правок и согласований, половина из согласующих перестанет читать документ, потому что они на это не подписывались и будут либо морозиться, либо принимать его не глядя. Потом они же вполне могут заявлять, что продукт сырой, многие требования не покрыты и так далее. Подписанное сторонами ТЗ немного увеличивает шансы на выигранное дело в суде, но не думаю что небольшая компания-интегратор мечтает судиться с условной Икеей.
2. ТЗ в 20-30 страниц это немного наивно) Даже задание на создание небольшого внутрекорпоративного сервиса с внятным описанием внутренней логики и интерфейсов занимает минимум 60-70 страниц с тенденцией уходить в бесконечность, а с серьезными системами с кучей интеграций всё обстоит еще хуже.
3. Вы не пишете ТЗ из воздуха, вы пытаетесь анализировать бизнес-процессы клиента (в идеале конечно). А для этого вы общаетесь с сотрудниками клиента, один из которых как назло в отпуске, второй вечно в командировке, третий не понимает чего вы от него хотите, четвёртый не может понятно ответить на вопросы и вечно уходит в пространные объяснения, перемежая их байками из жизни. В результате в ТЗ попадает процесс в некоторой степени похожий на настоящий. С интеграциями и ролями та же история, всегда есть какая-нибудь Маша, которую забыли занести в матрицу ролей, но без которой ни черта работать не может и не будет.
4. Следствие из п.3. На анализ, беседы, согласования правок, слёзы, панику и финализирование ТЗ легко может уйти от 3х месяцев до полугода (а в случае какого-нибудь ERP и год не удивит). За это время анализируемый бизнес немножко изменится 😊Кто-то внедрит новую систему с которой вам нужно будет в последний момент интегрироваться, кто-то чуть-чуть переделает смежный процесс, кто-то из числа ваших респондентов уволится и не сможет рассказать что он имел ввиду, когда описывал как должна работать фича. Факт в том, что ТЗ устаревает через день после его написания.
Есть еще куча подводных камней, которые тянут на полноценную статью, но резюмируя – имхо, ТЗ это в очень маленькой степени гарантия успеха внедрения или разработки. Это скорее фильтр при входе в проект для обоих сторон. Если заказчик может внятно сформулировать и написать что, как ему сейчас кажется, ему нужно – это плюсик к тому чтобы входить в проект. Для этого в целом и юзер-стори подходят, их внятно описать тоже не каждый в состоянии. Гораздо больше проекту помогут грамотная работа с клиентом (очень редкая штука в наших краях), риск- менеджмент и седовласый ПМ, который заработал первый инфаркт в 27 лет на проекте в ДальГазСтройАвтоматизации и спустя годы имеет чуйку на проблемы и способы их решения. Но в век аджайла все почему-то верят в ТЗ)

Ответить
17
Развернуть ветку
Андрей Солозобов

Типичное внедрение в малом бизнесе.
Действующие лица: В - владелец или гендир, М - менеджер верхнего звена (комдир, РОП и т.д.)

В: Нам нужно увеличить продажи.

М: Отлично! Я подготовил план. Для этого нам нужно внедрить CRM чтобы не терять клиентов, IP телефонию, чтобы фиксировать звонки и совершать больше звонков, настроить отправку e-mail и т.д. А еще нужно интегрировать 1С с сайтом.
Вот я нашел специалистов, которые внедрят CRM, интеграторов по 1С.

В: А тебе я за что плачу? Сам не можешь установить программу с CRM? У них на сайте все расписано, как это делается.
- IP вообще подключается одним кликом, я видел.
- Какие триггерные письма? Рассылайте всем наши прайсы.
- Мы что еще должны платить кому-то?
- Какие-то левые люди увидят нашу деятельность?

Иди лучше напряги менеджеров, да и сам сделай еще несколько звонков клиентам.

Ответить
11
Развернуть ветку
Аркадий Кашковский

ахаха... а вы в теме😂

Ответить
3
Развернуть ветку
Андрей Солозобов

А то.) Такие «успешные внедрения» проводил не один раз. Так что опыт накопил.))
Такая схема у многих компаний малого бизнеса. При этом они вполне работоспособны и выдерживают конкуренцию. Многие работают в excel, CRM в бумажном блокноте и в контактах телефона.
Принцип владельца:
- сделай небольшие изменения в текущих процессах (желательно бесплатно) и покажи, как это отражается на результаты. Тогда может быть выделим какие-то средства на другие изменения или внедрения.
Многие боятся глобальных изменений, так как до этого как-то дожили и не сгинули в конкурентной борьбе. Поэтому они по своему соизмеряют риски.

А вы говорите годовой проект от выручки считать)) 😅.

Ответить
3
Развернуть ветку
Аркадий Кашковский

Ахаха… ну да, это уже ближе к рокетсайнс для таких ребят)

Ну а по сути вопрос в целях, такое у том менеджеров ещё встречается, основная задача не сломать, а не сделать лучше и в итоге сидят в болоте и как-то существуют)

Ответить
1
Развернуть ветку
Маркет СБКгрупп

классическая схема. работал так с Амо. ахреневал по кривой интеграции

Ответить
0
Развернуть ветку
Yurii Bychkov

Вчера запретил выполнять задание клиента, потому что никто не отвечает на вопросы со стороны заказчика. Т.е. вместо ТЗ уже подсовывают ХЗ, но потом начнет "мы не это имели ввиду". Конечно всего не распишешь, но ТЗ помогает не приплетать к делу то, чего не было изначально и в этом иногда разница закончишь ты вообще этот проект или нет.

Ответить
1
Развернуть ветку
Аркадий Кашковский

Да, понимаю, история про 4 млн) Кажется о ней прямо нужно тут рассказать)

Ответить
1
Развернуть ветку
Yurii Bychkov

Т.е. тупить можно только на 4х млн? Остальное не считается?

Ответить
1
Развернуть ветку
Аркадий Кашковский

Не то чтобы не считается, скорее как частный пример)

Ответить
0
Развернуть ветку
Аркадий Кашковский

Александр, согласен с вами почти по всем пунктам, но прошу правильно интерпретировать. Ни в коем случае, я не говорил о том что это панацея, которая спасет от всех болезней.

По сути ТЗ это своего рода минимально необходимая гигиена, которая позволяет защищать интересы сторон.

А что касается сроков написания и изменений все так, и на больших масштабах наиболее целесообразно дробить работы на этапы, по возможности. Что бы ускорять процесс. Иначе можно пилить как продукты SAPа, по 5 лет, а потом понять что вообще в принципе это уже и не очень нужно. (Речь о больших продуктах, а не о новых направлениях которые заточены на более короткий цикл внедрения).

Ответить
1
Развернуть ветку
Маркет СБКгрупп

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

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

Ответить
1
Развернуть ветку
Shavkat Mavlonov

Согласен, но не всегда. Иногда наступает такие моменты, когда будет важен каждый символ Вашего ТЗ.

Ответить
0
Развернуть ветку
Evgeniy Zorin

Мне однажды в ответ на вопрос:
- У вас готово ТЗ?
написали:
- Вам изложить нашу Точку Зрения, или что?

Ответить
16
Развернуть ветку
Аркадий Кашковский

ахахха... кажется время собрирать тру стори)

Ответить
2
Развернуть ветку
Mickey White

Самое развернутое объяснение "пословицы"))

Ответить
13
Развернуть ветку
Аркадий Кашковский

Ахаха... мы старались)

Ответить
4
Развернуть ветку
Стас Иванов

Для таких "коллег по цеху" есть отдельный котёл в аду)

Ответить
6
Развернуть ветку
Аркадий Кашковский

Рынок, что с него взять🤷🏽‍♂️

Ответить
1
Развернуть ветку
Марат Булатов

Добрый день!
Я что-то не понял. Вы начали рассказывать как к Вам пришёл бизнес у которого была кривая срм, а потом километр теории, и нет конца истории про бизнес в начале. Что с ним стало? Он закрылся из-за кривой срм или Вы поработали, и всё стало ок?

Ответить
3
Развернуть ветку
Аркадий Кашковский

А это мы оставили специально для комментариев😈 Надо же вас всех как-то в диалог в тянуть😂

Ну а если серьезно, там написали детальное тз, по нему сделали и в итоге пользуются счастливые и довольные.

Ответить
5
Развернуть ветку
Leonid Evtushenko

байтишь просто)

Ответить
3
Развернуть ветку
Аркадий Кашковский

Я сейчас сидел и гуглил, что это значит и пытался понять что ты хотел сказать. Значит ли это что я староват и могу сказать: ясно, понятно?😂

Ответить
0
Развернуть ветку
Юрец

Это развести на активность из-за недосказанности)

Ответить
2
Развернуть ветку
Аркадий Кашковский

Аааа... теперь понял) Спасибо за пояснение)

Ответить
1
Развернуть ветку
Юрий Белоножкин

Да.

Ответить
2
Развернуть ветку
Аркадий Кашковский

Чуть выше раскрыл тайну)

Ответить
1
Развернуть ветку
Аркадий Кашковский

аахах... отличный пример)

Ответить
1
Развернуть ветку
Игорь Алексеев

Для того чтобы написать правильное ТЗ, заказчик как минимум должен понимать как у него устроены процессы в компании и возможности современных информационных систем, а таких людей ещё поискать. Туда же в копилку понимание, как можно поменять привычные бизнес-процессы, переводя их в цифру и автоматизируя при внедрении. Владелец живёт в вакууме, чаще всего с устаревшим пониманием всего. Генеральный - наемный сотрудник с желанием заработать и минимумом свободного времени, он может понимать ценность, но не детали в виде ТЗ. Маркетолог каждый месяц новый, ибо его забота в поиске рекламу настраивать, а такой каждый пятый на рынке труда. Директор по продажам сам в формате выполнения плана. Это про средний бизнес. Про малый вообще молчу, им до ТЗ ещё расти и расти.В общем вы думайте внимательнее, прежде чем работу предыдущих специалистов обсирать и себя героями выставлять, адресуйте посыл не всем участникам рынка, а взрослым компаниям. Единственный результативный путь для остальных - гибкое внедрение с промежуточными целями. И даже после такого главная проблема контроля останется. "Внедрить твою за ногу" - меньше половины дела. Контроль работы в CRM, соблюдение правил ведения, создание цифровых рабочих мест и офиса с автоматизацией, отчётность и автоотчетность, маркетинговые активности. В общем всё то что должно дать результат и принести пользу, требует контроля. Вы внедряете по ТЗ, сдаёте проект, клиент думает что после внедрения всё работает само по себе, а через полгода идёт к новому интегратору...

Ответить
4
Развернуть ветку
Аркадий Кашковский

Ну во первых, интегратора мы не "обсирали", а лишь говорили о проблемах имеющихся на рынке.

Во вторых, что касается проблемы ожиданий, тут все зависит от того как вы продаете, если вы кричите на каждом углу "Увеличим продажи за счет внедрения CRM" то на пресейле все красиво и продавать легко, а на деле понятно дело говно, потому что завышены ожидания.
Решается предельно простым способом, берем и на пресейле говорим:
1. У вас станет больше работы в первое время, систему нужно изучать и вести;
2. Сами сотрудники не начнут работать в системе, надо будет реализовать ряд мероприятий со стороны менеджмента, причем как до запуска проекта, так и после, что бы это все зашуршало;
3. То что мы сделаем, надо будет еще докручивать и поддерживать и снова платить за это.
4. И т.д. и т.п.
А потом спрашиваем, а оно вообще вам надо? Вы это понимаете и готовы к этому?
Вот тогда у заказчика формируется правильное представление о том что ему предстоит, но правда продажи падать начинают, ведь вокруг бегает толпа интеграторов которые пихают "волшебную таблетку".

Ответить
0
Развернуть ветку
Маркет СБКгрупп

вы не представляете, как часто были ситуации, когда рядовые продажники саботировали заполнение СРМ, в итоге ни о каких приближенных к действительности подсчетах конверсии речи не было.

Ответить
1
Развернуть ветку
Аркадий Кашковский

Ну так не путайте пожалуйста, проблемы.
Саботаж - это проблема в области менеджмента, которую надо решать соответствующими методами.
Проблемы связанные с отсутствием ТЗ, лежат в плоскости взаимодействия с интегратором и понимания конечного результата.

По вашей логике сюда и ковид можно притянуть: Не внедрили CRM, потому что ковид случился. И как нам тут ТЗ поможет?😂

Ответить
1
Развернуть ветку
Маркет СБКгрупп

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

Ответить
1
Развернуть ветку
Аркадий Кашковский

Ну тогда могу вам предложить сесть и ничего не делать, ошибок точно не будет😂

Ответить
0
Развернуть ветку
Маркет СБКгрупп

Подписываюсь под каждым словом.

Ответить
0
Развернуть ветку
Eduard Kozlov

Ох, опять эти продавцы ТЗшек. То, что вы описали - это ваша поделка, а не Техническое Задание. Её можно с огромной натяжкой назвать результатом джун BA (junior Business Analysis), но никак не Техническим Заданием. Этот документ стандартизирован как по ГОСТ (там для современных систем много избыточного), так и по IEEE (ближе к реальности, чтобы что-то выкинуть - нужно сильно постараться).
Где в вашей поделке нормальные нефункциональные требования, а не "облако-коробка"? Где в нем требования заинтересованных лиц, да и вообще их наличие минимум на трех уровнях? Если вы застряли на нижнем уровне на кого будете эскалировать? Ну я даже не говорю про один из важнейших блоков "ограничения системы", отсутствие которого на этапе приемки часто вылезает боком. Условно, у вас ограничение по железу на 100 сотрудников, а компания вводит в систему еще пару департаментов, сотрудников становится 300 и система начинает лагать.
Справедливости ради, то за то безобразие, которое вы привели в самом начале от других "интеграторов" - за такое надо руки отрубать и в причинное место вставлять. Причем можно прямо на законодательном уровне.
И, кстати, BA никак не противоречит Agile, любая методология разработки или внедрения отлично вписывается, это всего лишь Plan Driven или Change Driven подход, который уже отлично откатан.
А вообще, вы молодцы, что смотрите хоть немного глубже огромного количества самоделкиных на нашем непростом рынке!

Ответить
3
Развернуть ветку
Аркадий Кашковский

Эдуард, спасибо за конструктив, есть над чем подумать.

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

Ответить
1
Развернуть ветку
Eduard Kozlov

Эти ваши иллюзии о неважном и усложненном исчезнут после первого судебного разбирательства :)
Не, ну если мы говорим об уровне проектов, соизмеримых с судебными издержками, тогда да, вопросов нет. Это лишнее.
Удачи.
з.ы. Возможно, вы упростили подачу именно для vc, исходя из вашего сообщения выше это неочевидно, к слову о нефункциональных требованиях...

Ответить
2
Развернуть ветку
Аркадий Кашковский

Вы уловили ключевую мысль, про адаптацию текста для vc😜

Ответить
3
Развернуть ветку
Эразм Хемуль

Проблемы две. Если ТЗ пишет заказчик, то это нереально сделать. Если ТЗ пишет интегратор, то это не надо заказчику.

Вывод один: забить на интеграторов, нанять кодеров и писать в реальном времени то, что нужно.

И заметьте. Никакой фейсбук, гугл и прочие - никто не использует никаких интеграторов. Иначе они бы давно обанкротились. Везде свои отделы разработки.

И кстати, если посчитать, то свои программисты (или фриланс, что даже выгоднее) - это даже тупо дешевле. Я уж не говорю про то, что надежнее и точно будет результат.

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

Ответить
2
Развернуть ветку
Аркадий Кашковский

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

Во первых, если раскопать внутрь, то почти все корпорации используют услуги не только инхаус разработки.
Во вторых, компания у которой классический бизнес, зачастую даже не интересна крутым специалистам в IT, потому что там совсем другая ментальность.
В третьих, нормально сделанное ТЗ, решает именно проблему того что бы это отвечало задачам бизнеса и было реализуемо. А если происходит как в вашем примере, то там точно один из участников процесса "не оч", а может и оба🤷🏽‍♂️

Ответить
2
Развернуть ветку
Александр Орлов

Вот интересно. В строительстве есть архитектор. А хорошая архитектура это застывшая музыка)). Software Architect на большом мировом рынке понятный персонаж, с ответственностью за то, что получится. ТЗ это проект. Кодеры - строители. Ну заказчик понятно. А вот интегратор - это кто? Посредник который знает нужных людей и решает проблемы? ))

Ответить
1
Развернуть ветку
Аркадий Кашковский

А интегратор это прораб, без которого ничего нормально работать не будет, ну или если посмотреть шире застройщик, который организовывает все это в итоговый продукт.

Мне кажется как-то так)

Ответить
3
Развернуть ветку
Эразм Хемуль

И как, интересно, тетушки из бухгалтерии и вот этот вот тыжпрограммист напишут очень крутое ТЗ для интегратора?

Или как интегратор, который срать хотел на заказчика (у него ж там кипиай, да план продаж) напишет классное ТЗ?

Именно поэтому нормального ТЗ не бывает. Именно поэтому 70% внедрений не внедряются, а остальные 30% совсем не то, что было нужно.

И пока вы будете мечтать про волшебное ТЗ, которое с помощью магии и волшебства появится, нормальные люди наймут собственную команду и уже напишут продукт. И даже, наверное, уже будут им успешно пользоваться.

Но у вас, понятно дело, опыта намного больше. Расскажите подробнее!

Ответить
1
Развернуть ветку
Аркадий Кашковский

Ахаха... да вы мой друг совсем пессимист) Будет интересно узнать как написать ТЗ с тетушками из бухгалтерии, приглашаем вас заказать его у нас и сами все посмотрите)

Ответить
0
Развернуть ветку
Denis Ostrovsky

Если интегратор напишет ТЗ, которое клиенту не надо, клиент это не купит.
Почему в вашем уравнении нет варианта с интегратором, который вникнет в процессы клиента и сделает качественное ТЗ, которое будет понятным и клиенту и разработчику?
Не каждому бизнесу нужен инхаус отдел разработки

Ответить
1
Развернуть ветку
Аркадий Кашковский

Мне кажется это все опыт🤷🏽‍♂️

Ответить
0
Развернуть ветку
Дмитрий Луневский

Не согласен. Многие крупные ИТ компании, даже стартапы заказывают разработку части своих функций на стороне. Это очень видно на Европейском/Американском рынке. Иногда - так быстрее, чем найти человека с нужными компетенциями, иногда - так проще, когда задача на несколько месяцев. Например, для одного стартапа (ну как стартапа, уже инвестиций за 100+млн$) мы помогали в небольшой частной задаче, но эта задача была прямо одной из ключевых функций сервиса.

Ответить
0
Развернуть ветку
IA F

Хорошая статья. Жаль что ЛПР и ЛДПР ( не партия) их не читают, а их специалисты которым они поручают проекты запускать на стороне заказчика не могут/хотят им объяснить эти прописные истины.
Также многие заказчики просто не готовы выделять бюджет на проработку требований и ТЗ, ведь их реклама накрутила лозунгами "внедрим систему ща месяц за xx рублей".
Или "CRM это просто".

Ответить
3
Развернуть ветку
Аркадий Кашковский

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

Ответить
0
Развернуть ветку
Ilya Tkachenko

Отлично написано, прямо в рамочку можно вставлять с заголовком "Как надо делать".
Вопрос - создание такого детализованного и покрывающего ТЗ, процесс не быстрый и достаточно сложный/затратный.
Как заказчику объяснить, что ТЗ денег стоит? Ведь в итоге, ТЗ это не гарантия реализации проекта.

Ответить
2
Развернуть ветку
Denis Ostrovsky

Главное донести клиенту, что в его же интересах чтоб ТЗ было сделано. Если понимание важности ТЗ уже есть, но остался вопрос стоимости (почему так дорого), тогда следует позаботиться о том, чтоб донести клиенту какой объём работы будет проделан, желательно на готовых примерах.

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

Ответить
2
Развернуть ветку
Аркадий Кашковский

Мы обычно не отнимаем, а просто выделяем в отдельный этап, так понятнее из чего складывается вилка.

Ответить
2
Развернуть ветку
Аркадий Кашковский

Хороший вопрос, рецепта наверное нет, ну или я его не знаю🤷🏽‍♂️

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

Ответить
1
Развернуть ветку
Shavkat Mavlonov

Спасибо за крутую статью. То чувство, как будто вы написали историю нашего проекта которого еще не закончили. Все примеры и блок-схемы которые показаны, на 80% похожи ). Но учитывая те этапы которые приведены в статье, мы на правильном пути (благодаря нашим интеграторам), несмотря на те сложности которые в начале выглядели заблуждениями или ошибками.
Р.С. А те кто хотят подробное ТЗ по всем стандартам, рекомендую книгу Карла Вигерса 😉

Ответить
2
Развернуть ветку
Аркадий Кашковский

Ну все совпадения случайны) А так спасибо за теплые слова и успехов в реализации проекта)

Ответить
2
Развернуть ветку
Shavkat Mavlonov

Думаю причина совпадения, это как-то связано с Creatio )

Ответить
1
Развернуть ветку
Аркадий Кашковский

Ну примеры взятые в статье у нас на других системах реализовываются, точно знаю)

А вот то что мы во многом ориентируемся на стандарты компании Террасофт, это да)

Ответить
2
Развернуть ветку
Leonid Evtushenko

Крутая статья! Дам студентам почитать как пример

Ответить
2
Развернуть ветку
Аркадий Кашковский

Спасибо, даже не ожидал что настолько хорошо вышло)

Ответить
2
Развернуть ветку
Андрей Солозобов

Статья интересная и правильный посыл прорабатывать ТЗ.
НО! Как это часто и бывает, подрядчики любят оценивать возможности клиента, чтобы обосновать вложения. И как правило, не корректно, оперируя показателем «выручка». Правильнее использовать хотя бы «грязную прибыль». У одних компаний рентабельность 5%, у других 40%. От какого прироста выручки вы предлагаете выделить на проект 1/3? Надеюсь, не от годовой, которая ПОТЕНЦИАЛЬНО может увеличиться благодаря новым внедрениям?

Ответить
2
Развернуть ветку
Аркадий Кашковский

Тут смотрите, цифры приведены для примера. Поэтому на них ориентироваться не стоит... будем рады если дадите рекомендации как с этим работать, мы там просто отправили к финансистам)

Ответить
0
Развернуть ветку
Андрей Солозобов

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

Ответить
5
Развернуть ветку
Аркадий Кашковский

Справедливо, хочется сказать что это просто так сказали в статье) Но пусть это будет нашим маленьким поражением в этот раз)

Ответить
2
Развернуть ветку
Дмитрий Луневский

Мне тоже очень интересно как считаются условные 15млн руб за счет возможного роста? Я кучу статей перерыл, сам многократно пытался посчитать эффекты от внедрения CRM - близко к невозможному, это все подгонка под желаемый результат. Например, стало больше продаж тк меньше отказов. Это благодаря CRM? А может пришел классный менеджер, который все отказы прорабатывает или компания заказала правильный тренинг? Или маркетолог запустил кампанию на другую целевую аудиторию, и она априори готова лучше покупать?
И еще - а как дают 1/3 от выгоды? То есть условно, мы когда внедряем CRM для большой компании (на 1000 пользоватлей) выгода допустим измеряется в сотнях миллионах рублей. То проект должен стоить те же 33% от теоретически рассчитанного роста? Круто было бы )

Ответить
1
Развернуть ветку
Карина Калмыкова

Статья пушка-ракета 🚀

Ответить
2
Развернуть ветку
Аркадий Кашковский

Приятно слышать😜

Ответить
1
Развернуть ветку
БитЛаб

Спасибо за статью! Отправил заказчику)), иначе прям пошагово из вашей статьи действия " как не надо делать" будут выполняться

Ответить
2
Развернуть ветку
Аркадий Кашковский

ахаха... отлично, надеюсь поможет вам)

Ответить
0
Развернуть ветку
Alexey Vasilevsky

Не знаю как для ТЗ CRM, но для Т3 сайтов точно есть хороший тул Октопус

Ответить
1
Развернуть ветку
Маркет СБКгрупп

Это для создания структуры сайта, я правильно понял?

Ответить
0
Развернуть ветку
Alexey Vasilevsky

Именно так. + можно делать оценку в блоке estimate

Ответить
1
Развернуть ветку
Аркадий Кашковский

Интересно, изучим)

Ответить
0
Развернуть ветку
Хозяин

Какое ещё ТЗ? А как же Скрам, Аджайл, Канбан?

Ответить
1
Развернуть ветку
Аркадий Кашковский

А вы для канал "Клиент" случайно не пишите?😂

Ссылка для тех кто не в теме: https://t.me/yourtypicalclient

Ответить
0
Развернуть ветку
Константин Лолуа

У вас ошибки в схеме 5го этапа. Вот так нельзя

Ответить
1
Развернуть ветку
Аркадий Кашковский

Справедливое замечание, спасибо!

Ответить
0
Развернуть ветку
Юрич Юрич

Бросил читать после , в "Скажите, стоимость внедрения".

Ответить
0
Развернуть ветку
Аркадий Кашковский

Это вы для себя такую пометку сделали? Или что-то донести хотели авторам?

Ответить
0
Развернуть ветку
Читать все 81 комментарий
Праздник к нам приходит: когда заказывать подарки за рубежом

Ещё в ноябре для логистических компаний начинается горячий сезон, который продолжается до марта. 11 ноября — большая распродажа AliExpress, а сразу после неё — Чёрная пятница, плавно перетекающая в подготовку к Новому году, 14 и 23 февраля, и, наконец, к 8 марта. В это время Почта и другие логистические службы по всему миру доставляют особенно…

Сезон подкаста как эксперимент: научили ведущих бегать и отправили на полумарафон. Кейс Sports.ru и adidas
Чему я учусь у своих детей как предприниматель

Дети смотрят на мир открытыми глазами и у них есть чему поучиться.

Baring Vostok инвестировал $13 млн в российскую платформу автоматизации маркетинга Mindbox Статьи редакции

Деньги направят на развитие продуктов, опционный пул и сделки.

Фоторамка 2.0 или что подарить бабушке на Новый год

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

«Вам потребуется их благословение»: сооснователь iFixit — о самостоятельном ремонте от Apple Статьи редакции

Кайл Винс считает, что компания будет мешать замене деталей программно и установит высокие цены на товары для ремонта.

Talantix подключил интеграцию с Telegram

Облачная CRM-система для рекрутмента Talantix расширила возможности общения HR-команд с кандидатами внутри сервиса. К уже существующим интеграциям — с Viber и WhatsApp — добавился Telegram!

Как автоматизация работы юристов экономит время и деньги

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

Платежи в Южной Африке

Несмотря на то, что Южная Африка находится (сюрприз) в Африке, мобильные кошельки или QR-коды там совсем не используются, в отличие от большинства стран континента. И причина тому -- сильная банковская система, доставшаяся стране от Британской империи. Как следствие, в плане банковских услуг и платежей Южную Африку сложно отличить от…

Сбермобайл отказывает в переносе номера к другому оператору

1.12 написал заявление на переход в Тинькофф Мобайл, все стандартно, новый оператор сообщил о том, что заявку принял и перенос состоится через 9 дней. 4.12 от Тинькофф Мобайл приходит смс о том, что Сбермобайл готов перенести мой номер, спустя несколько часов я получаю уведомление об отмене переноса якобы по моей инициативе! Мои паспортные данные…

Как и чем сейчас живут московские рестораны, отмеченные гидом «Мишлен»

Узнали и рассказываем, как повлиял звездный статус на рестораны «Деликатессен» и «Паризьен», и за что их сотрудники получают повышенные чаевые.

null