Проработав 20 лет в ИТ, 8 из которых в должности CIO, а последние 5 в роли CEO ИТ-компании, я решил написать небольшую статью для тех, кто причастен к управлению цифровизацией бизнеса – собственников, CFO, CEO – но не имеет опыта ИТ-менеджера или ИТ-директора. Речь пойдет о стоимости и рисках принятия управленческих решений по разработке ИТ-систем внутри НЕ ИТ-компаний.
С кем не знаком – Андрей Балякин, CEO компании HubEx. Сейчас у нас в портфеле 2 продукта: собственно, платформа HubEx – решение для автоматизации выездного сервисного обслуживания, и MyQRcards – система управления электронными визитками в крупных компаниях. На примерах их разработки и продажи расскажу о характерных заблуждениях (“лакмусовых тараканах”) управленцев, которым приходится принимать решения по разработке и внедрению бизнес-систем. То есть ИТ-решений, на которые делается ставка при трансформации бизнеса от аналогового или полу-ручного (классического) управления к автоматизированной компании с развитой ИТ-инфраструктурой, с помощью которой происходит управление основными операционными процессами.
О чем мечтают все собственники?
Цифровой бизнес, управляемый с экрана ноутбука или смартфона – мечта любого владельца, инвестора и топ-менеджера. Каждый ИТ-менеджер или CIO не раз слышал от своего генерального директора или совета директоров:
“Нам нужно автоматизировать компанию так, чтобы видеть ее пульс на экране смартфона, а менеджеры могли управлять показателями работы, не вставая с рабочих мест. Двойной ввод данных должен быть исключен, а ручные операции сведены к минимуму!”.
И вот уже перед ИТ-руководителем ставится задача автоматизации всего и вся. Причем чем меньше компания, тем меньше на это выделяется времени, а понимание бюджета такого мероприятия исчезает пропорционально размерам организации.
Не могу вспоминать без улыбки слова уважаемого CFO в присутствии акционеров компании, где я трудился ИТ-директором некоторое время назад: “Андрей, вы собираетесь внедрять систему документооборота и автоматизировать процессы согласования целый год? Это немыслимо! Вон мы, в _называется крупный машиностроительных холдинг_ запустили SAP за 3 месяца!”. И недвусмысленный взгляд, мол, мы тут все "студенты"… =)
Речь о том, что поспешность в принятии решений топ-менеджерами чаще всего связана с отсутствием реального опыта в соответствующих проектах. Об этом и решил немного рассказать на личном опыте.
Лакмусовый таракан №1: единая система управления бизнесом существует
Как бы ни так. В мире существуют десятки различных классов ИТ-систем. Каждый класс систем решает свои задачи: CRM – управление взаимоотношениями с клиентами, ERP – управление ресурсами предприятия, WMS – управление складом, Service Desk – управление заявками и уровнем сервиса, SCADA – диспетчерское управление и сбор данных об оборудовании, FSM – управление выездным обслуживанием, BPM –управление бизнес-процессами, и т.д.
И все эти системы существуют не просто так. Каждая из них решает свой класс задач, и такие системы образуются в иерархии (пирамиды), без выстраивания которых не получится гибко управлять крупной компанией. Если пытаться функции систем разных классов реализовывать в одной системе, провал неизбежен. Будет построен “мост из чугуна”, которые попросту развалится под своим весом. Крупным компаниям приходится внедрять десятки ИТ-систем и интегрировать их между собой, чтобы механизм мог работать и им можно было пользоваться.
Вот так, например, может выглядеть пирамида ИТ-систем в производственной компании
Если пытаться из ERP-системы сделать АСУТП, ничего не выйдет. Максимум, можно попробовать реализовать функции систем смежных уровней. И то, делать это следует, принимая во внимание множество различных факторов. В той же мере у вас не выйдет сделать из Service Desk системы сделать полноценную систему управления выездным обслуживанием (FSM).
Для крупных организаций с оборотом, скажем, от 1 млрд. в год единой системы не существует! Это всегда набор интегрированных специализированных систем, взаимодействующих друг с другом. Только небольшие организации с оборотом в десятки или сотни миллионов рублей в год могут более или менее качественно автоматизировать бизнес на базе одной системы. И еще. Многие топ-менеджеры думают, что внедрив, скажем, SAP, у них появится эта единая система. Это не так. SAP, IBM, 1С или Microsoft – это экосистемы, состоящие из десятков и даже сотен ИТ-продуктов, которые нужно интегрировать между собой и строить вручную ИТ-решение через дорогостоящие и долгосрочные проекты внедрения систем различных классов.
Другое дело – небольшие компании. Если не ставить задачу автоматизации всего подряд, а выбрать бизнес-критичные операционные процессы, то одна-две системы могут быть внедрены и по праву называться “единой системой управления бизнесом”. Конечно, часть работы по прежнему останется в ручном режиме, но зато автоматизация не будет стоить миллионы.
Лакмусовый таракан №2: дешевле самим разработать ИТ-систему, чем покупать чужую
За 5 лет управления продуктовым ИТ-бизнесом в HubEx к нам приходили сотни уважаемых компаний всех размеров – от малого бизнеса до крупного enterprise. (Напомню, HubEx – это специализированная ИТ-система класса FSM, Field Service Management или, по-русски, система управления мобильным сервисом).
Большая часть этих компаний рассматривала HubEx в сравнении либо с уже разработанной внутри системой со схожими функциями, либо знакомились с решением, чтобы разобраться в методиках управления выездным сервисом, заложенных в системах такого класса, и разработать свое подобное решение с нуля (иными словами, занимались промышленный шпионажем). Ко многим таким встречам я подключался лично и открыто делился всей имеющейся у нас информацией, чтобы потенциальные клиенты, обладая всей картиной, могли принять взвешенное решение и, возможно, отказаться от планов по разработке собственной системы.
Подвожу итоги и фиксирую успехи тех, кто ушел, выбрав разработку своего решения:
10% клиентов вернулись через год-два внедрять наш HubEx. Так как трезво оценив объем необходимых инвестиций в разработку собственного решения, поняли, что дешевле и быстрее купить и внедрить готовое, чем разрабатывать пару лет что-то с нуля без какой-либо пользы для бизнеса в течении этого немалого срока. Все эти клиенты пришли к выводу, что разработка своего обойдется в десятки и даже сотни раз дороже, не говоря уже о дальнейшей поддержке.
Около 15% потенциальных клиентов запустили собственную разработку. Сделали что-то, что по функционалу в десятки раз уступает специализированному решению и абсолютно не удовлетворяет возросшим во время разработки требованиям. Такие компании часто потом приходят с запросом на внедрение HubEx и попыткой интегрировать свое решение с нашей платформой, чтобы как-то использовать и оправдать расходы на то, на что уже потрачены миллионы, и что до сих пор не привело к желаемому результату.
-
Несколько компаний, которые начали разрабатывать собственные решения, набрали штат разработчиков с ФОТ в несколько миллионов рублей в месяц. Чтобы как-то оправдать инвестиции, которые никак не окупились полученным эффектом, часть компаний пытались вывести свой продукт на рынок. Такие компании только через год-другой начинают понимать всю трагичность ситуации. Разработать решение и успешно продавать – это два абсолютно разных процесса. Кроме того, чтобы продать то, что было сделанное для своего бизнеса, чаще всего систему приходится переписать целиком, заложив новую архитектуру.
Успешного бизнеса не получилось ни у кого из них, все только потратили. Если кто-то не согласен – пишите примеры в комментариях, обсудим. Я таких примеров не знаю.
Остальные (больше половины) так ничего и не сделали, потому что собственники хотят свое, свято веря, что свое лучше, чем внедрение готового продукта от вендора. Но для бизнеса важно, не "как", а "что" – результат важнее процесса. Про это часто забывают, ставя цель сделать свое и не оценивая реальные затраты на разработку и дальнейшую поддержку. А когда вписались, уже жалко бросать.
Отсюда следует следующий "лакмусовый таракан".
Лакмусовый таракан №3: разработать своё несложно, достаточно написать требования и взять пару разработчиков в штат
Эта тема заслуживает отдельной статьи, но попытаюсь коротко. Для тех, чьи управленческие решения по части ИТ могут стоить бизнесу десятки и сотни миллионов плюс упущенная выгода из-за потери времени. Времени на сбор команды, разработку и прохождение пути от подготовки требований до тестирования, запуска и последующих доработок нового решения уровня ERP.
Любое (это важно, любое!) ИТ-решение уровня ERP или BMS состоит из:
Бизнес-анализа
Архитектуры
Back-end сервисов (это база данных и API, которые позволяют хранить данные и общаться с данными извне и интегрировать систему с другими системами компании)
Front-end сервисов (это то, с чем взаимодействует пользователь: веб-интерфейс системы и мобильные приложения, когда необходимо)
Data Analysis (система отчетов и аналитики, без которой любая корпоративная ИТ-система будет бесполезна)
Infrastructure (инфраструктура и вспомогательные сервисы под вашу систему, т.е. кластеры – специальным образом настроенные сервера с операционными системами и различными программными компонентами–, различные установленные готовые компоненты, позволяющие реализовать те или иные функции вашей ИТ-системы. Например, система логирования данных или отправки PUSH-уведомлений на смартфоны и т.п.)
Тестирования. Без качественного и поставленного процесса тестирования любая ИТ-система обречена
Поддержки. Если пользователи начнут напрямую общаться с разработчиками, это тупиковый путь. Команда разбежится быстрее, чем вы что-то успеете с этим сделать
Дизайна. За красоту и написание кода отвечают разные полушария мозга, а значит, без дизайнеров и UI/UX специалистов ваши разработчики понаделают такого, что не один пользователь не разберется.
-
Возможно, я что-то забыл, но написанного и так хватит, чтобы сложилось понимание, что такое ИТ-продукт, и почему один или два разработчика ничего не могут разработать в организации с нуля.
Если вы планируете систему не только для своей компании, а для рынка, то к этому добавится:
Организация отдела продаж
PR, маркетинг
Аккаунт-менеджмент
Коммерческая составляющая
Давайте посчитаем, сколько стоят хотя бы пункты 1-9
Рассчитаем минимальный бюджет, без которого любое начинание собственной разработки в компании, будет провальным. Цены на ФОТ привожу питерские. Причем за эти деньги вы, скорее всего, не сможете собрать команду, так как спрос на рынке ИТ в разы превышает предложение, и сегодня вы не сможете конкурировать со Сбером, Тинькофф, Мэйл.ру или Яндекс. А если нанимать в проект джуниоров, тем более на начальные стадии, неопытные ребята гарантированно похоронят проект из-за ошибок в архитектуре или попросту некачественного кода.
Итак, какие сотрудники потребуются в команду разработки решения класса ERP / BMS / FSM / WMS / SCADA и т.п., чтобы разработать продукт с нуля? Их средние зарплаты на лето 2021 года.
Итого, больше 2 млн руб. в месяц без учета сопутствующих по содержанию офиса, административных функций, премий, ДМС, фитнеса, снеков и других нематериальных мотиваций, которые все больше предлагают ИТ-компании сотрудникам в компенсационном пакете.
Но как уже писал, маловероятно, что даже за эти деньги вы соберете команду. Уже несколько лет рынок ИТ растет как на дрожжах, а опытных разработчиков в разы меньше, чем требуется компаниям в борьбе за место под солнце при всеобщей цифровизации.
Так что если вы не готовы выделять на проект разработки ИТ-системы класса ERP / BMS / FSM и т.п. менее 40 млн. в год, единственный выход для вас – выбрать одно из наиболее близких по функционалу платформенных решений и сделать свое решение на его базе. То есть не с нуля, а доработав систему под задачи своего бизнеса. В этом случае расходы окажутся на порядок меньше, а результат не заставит себя долго ждать.
И минутка рекламы. Если вы планируете разработать систему для управления мобильными сотрудниками, то наша платформа HubEx максимально подойдет для решения данной задачи. Компании со всей России из более чем 40 отраслей сервисного бизнеса уже реализовали собственные решения для автоматизации управления мобильными или выездными сотрудниками на базе нашей платформы. Бюджеты данных проектов вас приятно удивят, а результат будет гарантирован опытом других компаний из вашей отрасли, которые уже выстроили свою “сервисную ERP” (точнее FSM-систему) на базе платформы.
Как всегда, буду рад проконсультировать и ответить на вопросы здесь или в Facebook, Instagram.
Комментарии (21)
Win08
26.08.2021 16:33Если взять 1С, то можно смело поделить на три, а может и на четыре.
amatoravg
26.08.2021 18:16Дык, об том в статье и речь. Вы же для внедрения коробочное решение от 1С вначале приобретете, а не на голой платформе писать с нуля будете.
Andrei_B Автор
26.08.2021 18:25Верно. 1С это платформа. Правда, например, FSM систему написать на 1С не выйдет, как и ряд других классов решений. Но 1С действительно отличная альтернатива написания решений с нуля.
amatoravg
26.08.2021 18:45Как же не выйдет :) Уже много лет на рынке имеется отраслевая конфигурация - 1С:ТОИР Управление ремонтами и обслуживанием оборудования, с сотнями внедрений. Разве это не FSM? Хотя в каталоге это ПО стоит в разделе СММ, ЕАМ.
Andrei_B Автор
26.08.2021 19:15+2FSM это управление выездным обслуживанием. ТОиР организует обслуживание оборудования, а FSM управляет сотрудниками обслуживающими оборудование. Есть опыт написания мобильных приложений для ТОиР и тогда такая система начинает базово управлять мобильном персоналом, но именно как опция. Я бы сказал так: FSM это в том числе лайт ТОиР. И из ТОиР можно слелать lite FSM.
Win08
27.08.2021 10:35не на голой платформе писать с нуля будете.
Можно и на голой платформе, зависит от задачи. Не, БСП можно прикрутить, но это все равно на голой.
Как сейчас говорят, мой поинт в том, что бэк-энд разработчких, фронт-энд разработчик и мобильный разработчик в 1С это один и то же человек. Да и отчеты и архитектура — это все тот же самый разработчик 1С ))) Да и дизайнер это тоже все тот же самый человек.
Вот техподдержку и тестирование, да, разумно переложить на другого человека.
Итого: заказчик/владелец, разработчик 1С, тестирование/поддержка/аналитика/дизайн, системный администратор. Вот и все роли.Andrei_B Автор
27.08.2021 11:16Да. Так и есть. Правда 1с разработчиков понадобится не один. На платформе разрабатывать в разы быстрее и дешевле, даже принимая во внимание ограничения, которые она накладывает. Меня искренне удивляют компании принимающие решения разрабатывать софт для себя и без платформы. % успешности таких начинания близится к 0.
Win08
27.08.2021 11:51Так в предлагаемой структуре: 4 бэк, 2 фронт, 2 мобильных, 1 архитектор, 1 на отчеты = 10. А тут, конечно в зависимости от того что разрабатывают, может быть 3-4 разработчика. И взаимозаменяемость у них высокая, и 1с-ники стоят, в среднем, немного дешевле и в случае если кто уволился, все-равно кто-то остался. А так, оба с фронта ушли, и все, сливай воду.
PS. В предлагаемой штатке 17 человек. Наверное кто-то может наниматься проектно, но тот факт что должности в единственном числе несет большие риски. Уволился аналитик — и все, даже если все хорошо задокументировано, все остановилось.
А если заказчик (он же владелец) — 1 шт ;) разработчик 1С — 4, и группа аналитики/техподдержки/тестирования — 4. Итого 5 человек. Если заказчик «уволится» то актуальность проекта уже под вопросом. А уход одного, и даже двоих, из любой группы, да, будет ударом, но не критичным, можно принять новых людей и будет кому их обучить, им подсказать и т.д.
Да, еще админ нужен, но если контора более 100 сотрудников, то админ у них скорее всего уже есть. Возможно понадобится на 20-30% ему поднять з/п.
PPS. По з/п, если это за МКАДом, то один разраб на 150, и два по 100 и один на 70. В группу техподдержки один на 150, два по 100, и один 70. Итого 810 тыр, уже не 2,16 ляма. Я конечно чего-то забыл. Но думаю что и в штатке в статье тоже что-то не учтено.Andrei_B Автор
27.08.2021 11:57+1А разработкой приложения на 1С под iOS / Android кто будет заниматься? Кто под мобилку API будет писать? На 1С я видел только очень слабые и неудобные приложения, если честно. С офлайн режимом вообще не встречал. Дизайн под мобилку кто будет рисовать?
Win08
27.08.2021 13:13У 1С есть мобильный клиент (тоже самое что и тонкий клиент, только работает на смартфонах, специально что-то писать не надо, просто указываешь путь к БД и все, хотя, конечно, адаптировать формы под вертикальный формат лишним не будет, но не обязательно), как под Андроид так и под iOS. Если речь про внутренний продукт, т.е. тот которым пользуются сотрудники, то iOS не нужен чуть более чем совсем.
Если речь о продукте «на рынок» тогда это уже софтверная контора и там совсем другой расклад.
PS. И веб-клиент есть, т.е. можно просто работать в браузере, а с 3.18 можно и PWA «установить» и не занимать вкладку в браузере ;)Andrei_B Автор
27.08.2021 13:25+1Мы пытались с его помощью, пару лет назад, сделать решение для согласования договоров и т.п.
Там все слишком ограниченно и, например, мобильное приложение для выездного персонала на этой технологии будет мало жизнеспособно. Офлайна там нет, видов полей данных мало и т.д. Когда в компании сотни сотрудников и они меняются, мобилка должна быть удобной, как для работы, так и для администрирования.
И ещё была проблема, что поле установки этого клиента нужно было прописывать ручками сервер итп для подключения. Так и осталось?
В общем для некоторых задач и небольшого количество апользовтелей - моб клиент 1С подойдёт. Но для удобной работы большого количества сотрудников, нужно будет писать отдельное мобильное приложение, делать API и писать бэк. А это уже +Х сотрудников.
Win08
27.08.2021 15:57Серебряной пули никто не обещал ))) Но и оффлайн там есть, и виды полей ограничены только фантазией… да, 1С, мне за рекламу не платит )))
Вопрос был в том, что инструмент надо выбирать в зависимости от задач.
С уважением,Andrei_B Автор
27.08.2021 20:30+2Понятно )
1С, кстати, мы встроили в платформу модулем, чтобы быстро расширять функционал.
EvgeniyCh
30.08.2021 15:50+2Боюсь конечно, что с четырьмя разработчиками вы свою условную CRM (и тем более ERP) с нуля не напишите. Даже на 1С. Как минимум нужны еще роли функционального архитектора, методолога, аналитика, тех райтера, владельца продукта/руководителя проекта/или любого другого отвечающего головой за продукт/проект. Понятно что каждый сотрудник будет совмещать по 2-3 роли. Но тем не менее для разработки полноценного ПП в придачу к разработчикам, даже таким "многоруким" (в хорошем смысле) как в 1С, нужны еще профильные специалисты.
Да и зарплаты в 70-100 тысяч для хороших разработчиков 1С, даже в заМКАДье уже скорее из области фантастики. Откройте hh в условном Новосибирске, уже там переханчивают удаленно специалистов на ЗП 125+. В СПб уже 2 года назад за 70к толкового джуна нанять было проблематично.
Filmaniko
04.10.2021 06:48+2Возможно подытожу.
У современных компаний, будь то маленькие или большие, всегда мега амбиции.
CIO в таких компаниях, зачастую недавние начальники отдела ИТ, которые готовы исполнять любую прихоть руководства, дабы удовлетворить потребности. При этом неудачи, которые в последствии терпят проекты собственной разработки эти CIO либо перекладывают на руководство :"Ну это же вы давали задачу" , либо принимают на свой счёт: "Пора искать другую работу!"
Не готов давать себе оценку, но мне хватило одного года, чтобы понять, что в мире бизнеса, CIO без стальных яиц становится ручным админом собственника. В итоге замученные сотрудники, куча потраченных денег и не достигнутые цели.
Во время, когда кол-во стартапов в день превышает количество рождённых детей в стране, производственным компаниям необходимо использовать готовые решения. Перепилив их под свой бизнес.
Такие гиганты, как Тинькоф или Сбер, вполне оправданно вкладывают в разработку и приобретают компании по разработке в свой портфель активов. А небольшие то куда лезут?
Владелец компании по сбору и реализации металлолома, какие бы амбиции у него не были, никогда не поймёт почему запланированные сроки разработки были сорваны. Какого бы CIO он не нанял. В этом случае разработку нужно выделять в отдельный бизнес. Не подконтрольный абсолютно. Но это же по сути просто подарить кому то денег на развитие.
Статья годная и точная. Каждый должен заниматься своим делом.
Andrei_B Автор
13.10.2021 21:58Я бы еще отметил, что даже выделив ИТ в отдельный бизнес, не получился угодить "и вашим и нашим". Решение сделанное под задачи конкретного бизнеса в 99% случаев никому больше не подойдёт без серьёзных переделок, а скорее новой разработки. Решение для рынка строится совсем по другим принципам.
Karroplan
DevOps настраивает сервера, поддерживает сервера... бэкапит, обновляет компоненты... Кажется автор не разобрался с разницей между сисадмином и девопсом. Про 110к за девопса тоже смешно.
Andrei_B Автор
Ваше определение DevOps? В моих компаниях это то, что написал я. И ЗП тоже не с неба.
Karroplan
devops - это тот человек, который занимается проблемами доставки приложений от разработчиков в окружение продуктивной эксплуатации. И всем что с этим связано - автоматизацией доставки, цепочками окружений, разницей между dev-environment и prod-environment, обновлениями, но не серверов, а приложения на серверах при выпуске новой версии.
https://www.redhat.com/en/topics/devops/devops-engineer
а вот то, что вы написали - это обычный it-operations.
а за хорошего админа, который может и сеть настроить, и серверы, и виртуализацию/контейнеры, и бэкапы и потом еще и разработчикам рассказать как все это должно пользователей обслуживать - во-первых таких нет, а если есть - стоят раза в два дороже.
Andrei_B Автор
Кстати да. Согласен с вами. В идеальной картине мира - так и есть. Но в реальной жизни - функции смешиваются. Без девопса можно жить. Их выделяют в отдельные функции до сих пор небольшое количество компаний. В остальных - их задачи разбирают админы и бэк-разработчики.
А что по З/П девопса сегодня в рынке? Ориентируетесь?