Что важнее при запуске ИТ-проекта: процессы или разработка?

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

К каким поставщикам ИТ-услуг бегут заказчики?

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

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

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

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

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

Заказывали систему «охрененно»? Раз, два, три — готово!

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

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

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

Это как раз одна из точек отказа больших проектов, в том числе внедрения СРМ. Чтобы составить грамотное ТЗ и переложить его на софт, нужна определенная компетенция — глубокое понимание конечного продукта и как этот продукт впишется в рабочие процессы.

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

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

Сотрудники компании быстренько и кое-как лепят ТЗ. Разрабы пилят, опираясь только на часы. И вроде бы задача решена, но мы пришли к неполноценному результату. Каждая сторона была вовлечена ровно настолько, насколько ей хотелось, далеко не на 100%. Проблему не нужно было решить, а нужно было отчитаться, что она якобы решена. 

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

Кстати, никакой экономии может и не быть. Случается, что технические ребята убеждают руководителя компании, что регулярно нужно выделять n (с 4-5 нулями) рублей бюджета на докрутку решения. 

Казалось бы, как можно постоянно дорабатывать готовый продукт автоматизации на одной и той же бизнес-модели? Да, если компания идет в развитие, появляется новый функционал — это понятно. Но если процессы не меняются, то зачем нужна вечная допилка? Может технические ребята просто «вешают лапшу на уши» заказчику и, таким образом, выманивают деньги?

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

Описание процессов и грамотное ТЗ — залог успешной автоматизации

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

Стандартизация и описание процессов — главное условие успешного внедрения. Пока все сотрудники не начнут работать по четкой логике и шагам 1–2–3, ни о какой автоматизации не может идти и речи.

Например, мы хотим с помощью CRM автоматизировать работу менеджеров по продажам. Для заключения сделки сотрудник должен проделать работу, состоящую из следующих этапов:

1. Новая заявка.
2. Заявка взята в работу.
3. Выставление КП.
4. КП отправлено.
5. Договор составлен.
6. Договор отправлен.

После этого составляется регламент работы отдела продаж — документ, в котором детально описывается, что нужно делать менеджерам на каждом этапе. Например, описание этапа «Новая заявка» может выглядеть так ↓↓↓

На основании регламента составляется ТЗ, где также описывается каждый этап процесса.

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

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

Со стороны всегда виднее!

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

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

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

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

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

Кейс из личного опыта

Мы разделяли айти-инфраструктуру в одной крупной компании. Это был осознанный «развод по любви», когда из одной большой компании делали две: материнскую и дочернюю. 

Разделить ИТ-инфраструктуру нужно было так, чтобы ни одна из сторон не потеряла в качестве пользовательских сервисов.

Весь процесс состоял из трех этапов:

1. Обследование и анализ. На этом этапе мы проводили аудит текущей инфраструктуры. Смотрели, какие точки наиболее критичные. Исследовали пользовательские пути: каким образом клиенты ходят на тот или иной сервер. Знакомились с тем, как у них устроены почта, интернет. Анализировали, что можно реализовать на существующей технической базе, а что нет.
2. Разработка схемы перехода. Наш инженер и сотрудник со стороны клиента составили ТЗ, каждый пункт которого был одобрен заказчиком. В ТЗ входили описание схемы и топологической структуры сети, оборудование, на которое переносятся компоненты ИТ-инфраструктуры, применяемые технологии и решения, порядок сдачи объекта в эксплуатацию. Перед реализацией проекта было проведено предварительное тестирование, чтобы сделать переход быстрым и снизить вероятность ошибок.
3. Исполнение проекта. Физическое разделение ИТ-инфраструктуры.

Весь проект длился три месяца. При этом работа руками (разделение ИТ-инфраструктуры) заняла всего 2 дня. Еще несколько дней ушло, чтобы убрать мелкие недочеты.

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

Заказчик этого проекта оказался достаточно адекватным: он понимал дополнительные консалтинговые траты.

А напоследок про магов

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

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

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

Как правило, правление мага длится 3–4 месяца, потом его разоблачают и со скандалом выгоняют из компании.