- -
- 100%
- +
Еще стоит поговорить об “излишнем фанатизме”. Автоматизация – это всегда здорово, но стоит хорошо подумать стоит ли ставить систему WMS (управления складом) для фактически кладовки площадью 40 квадратных метров и одним кладовщиком или крутую систему бюджетирования, если у вас всего десяток сотрудников и фактически один центр финансовой ответственности в виде вас самого – любимого.
Нужно четко представлять, чего вы ждете от ИТ-системы. Какой эффект она может принести, кроме того, что вы сможете где-то прихвастнуть (хотя это тоже иногда требуется). Кстати, тут еще есть место одному мифу. Крутая система автоматизации увеличивает стоимость компании при выходе на биржу. Когда это кто-то будет утверждать просто попросите его ответить на вопрос: “а на сколько?”. Сам по себе бренд системы не факт что кого-то интересует. Интересуют результаты, а они выражаются в “цифрах на табло”: товарообороте и прибыли – остальное все не существенно. Мне приходилось сталкиваться с аудитом, который проводили при выходе на биржу. Самый крутой тест выглядел так: нам принесли несколько чеков из различных магазинов и попросили показать, что они отражены в информационной системе.
Посмотреть на себя – это очень правильно, но так же правильно посмотреть вокруг себя. Задумавшись о выборе ИТ-системы стоит выяснить, а как обстоят дела у окружающих: что они используют, как работают. Безусловно, почетно быть первопроходцем, но их удел не всегда столь героичен, как представляется. Это как про дельфинов. Мы знаем про случаи, когда они кого-то притолкали к берегу, но нам никто не может рассказать о том, как они кого-то оттолкали в море.
Выбирать модное и новое – это большой риск. Если у вас 10000 магазинов, то поставить эксперимент на 10 – это вполне оправдано, но если их у вас всего 10, то выпадение даже одного может стать фатальным для бизнеса. Современная история знает случаи, когда смена версии программного обеспечения учетной системы у одной компании с весьма солидным оборотом парализовала ее деятельность на несколько недель. Хорошо, что за ней стоял другой финансовомощный бизнес, иначе все могло бы закончится плачевно.
Если в вашей сфере деятельности, есть какое-то проверенное отраслевое решение, адаптированное к вашему рынку – это будет лучший выбор.
Следующими важными факторами, которые стоит учитывать – это наличие ресурсов времени и денег. Выбирать нужно по средствам и с учетом стоящих перед вами временных ограничений.
Любимая тема всех продавцов программного обеспечения для бизнеса: мы можем это доработать под вас. Почему-то на этапе продажи это звучит легко и естественно, а после начинаются трудности в виде превышений бюджетов и сорванных сроков.
Мы уже говорили, что выбор ИТ-системы сродни выбору религии. Вы можете нанять строителей и вам построят прекрасный храм, но наиболее важным является найти жрецов, которые будут осуществлять служение. Здесь аутсорсинг не уместен.
Основной вопрос это обзавестись тем, кто будет поддерживать идеологию ИТ-системы и развивать ее. Без этого дело можно считать безнадежным.
Люди решают все. У них свои предпочтения, свои планы и приоритеты. Можно найти суперкрутую систему, поставить ее и столкнуться с тем, что ей попросту некому будет заниматься. Работая на Дальнем Востоке я столкнулся с ситуацией, когда в наличии была потенциально очень приличная система для нужд бизнес-анализа, но по факту она не выполняла своих функций. Мы нанимали, учили специалистов, но как только они начинали, что-то из себя представлять и от них должен был вот-вот начать поступать какой-то выхлоп, они мигрировали либо в Санкт-Петербург, либо в Москву. Людей не интересовали деньги – они меняли регион жительства.
Перед тем как делать выбор системы – лучше вначале найти и нанять специалиста. В моей истории был случай, когда меня пригласили на должность ИТ-директора во вновь создаваемую украинскую торговую сеть. Ситуация получилась “без меня меня женили”. Оказалось, что наблюдательным советом был уже заключен договор с одной известной в мировых отраслевых кругах ближневосточной компанией на комплексную автоматизацию. До запуска сети было меньше 3 месяцев, в которые еще умещались и рождественские каникулы. При этом выяснилось, что партнеры плохо себе представляют, что такое учет товародвижения в Украине. “Торг-12” привела их в ступор. То, что цены нужно назначать централизовано и нужно было вести единый справочник товаров тоже. Особо изысканным требованием была необходимость расчета себестоимости в операционном контуре. По большому счету у них в запасе была только надежная, как танк, кассовая система, которую они реально внедрили в ряде очень авторитетных мировых сетей и благодаря которой получили авторитет на рынке.
Сразу остановлюсь на одном моменте. Когда какая-то ИТ-компания говорит, что они сотрудничают с кем-то, то это скорее всего означает лишь то, что в зоопарке данного партнера, есть его одна или несколько зверушек.
Если возвращаться к украинской истории, то нам пришлось переобуваться в воздухе. Большинство сотрудников было приглашено из другой торговой сети и мы приняли решение о внедрении решения, с которым они имели дело на предыдущем месте работы в роли учетной системы, оставив кассовую систему, прошедшую определенную доработку. Все прошло успешно и с некоторыми нюансами, но все заработало. Реально на все ушло порядка 8 недель.
Как определить правильный ли выбор вы сделали?
Казалось бы самый правильный вариант это спросить пользователей от их уровне счастья от обладания системой. Но оказывается, что уровень счастья больше зависит не от системы, а от отношения к ней пользователей.
Часто люди недовольны, потому что им не хватает каких-то мелочей, фактически бантиков. А иногда они довольны несмотря на то, что приходишь и видишь, что у них не автоматизированы простейшие вещи и им приходится работать не покладая рук Все зависит от их кругозора, опыта, фантазии и уровня интеллекта.
В моей практике достаточно распространенным случаем является ситуация, когда человек ноет, что “у нас все плохо, у нас система никакая”, а после ухода через пару месяцев при встрече заявляет, что “у нас все было супер, и система была лучшей в мире”.
Глава 9
Как создать и развивать свой продукт?
Если лучший автомобиль – это служебный с водителем, то лучшая система – это та, которую создал ты сам.
Это совершенно не означает, что все необходимо делать самостоятельно с самого-самого начала. Я говорю про здоровую долю кастомизации или доработки системы под нужды конкретной компании. Нужно понимать, что когда вам говорят, что компания “сидит” на том или ином продукте, например 1С или SAP, то это совсем не означает, что они используют одинаковый типовой функционал.
Дважды мне приходилось сталкиваться со случаями, когда ИТ-директор проповедовал, а руководство организации его поддерживало, позицию, что мы используем только типовые решения от вендора и ничего не дорабатываем за исключение отчетов. Сказать, что уровень автоматизации этих компаний меня впечатлил нельзя – скорее наоборот. Но такое решение может быть вполне рабочим, хотя его эффективность вызывает сомнения. Для среднего бизнеса использование совсем типовых решений может быть вполне оправдано. Минус штат разработчиков, постановщиков, плюс пара десятков дополнительных рук в операционке – наверное, выйдет то ж на то ж.
Но как только компания становится по настоящему большой, то десятки рук превращаются в сотни. И к этим сотням рук добавляется еще десяток голов, которые ими должны управлять, потом еще учить, потом контролировать, исправлять. В общем эффективность начинает падать. Система управления требует внедрения других процессов и применения нетиповых решений.
Большой бизнес не может быть типовым и тут возникает потребность создания своего продукта. И появляются программисты, постановщики, консультанты, как свои, так и привлеченные извне. У ведущих торговых сетей РФ количество людей задействованных в изменениях ИТ-системы исчисляется сотнями. Эти сотни людей обрабатывают тысячи заявок и хотелок, которые достаточно хаотично сыпятся от подразделений – система получает уникальность.
Особый случай – это когда компания развивает свое совсем уникальное решение на базе полностью внутренней разработки, а не платформы, представленной на рынке каким-либо производителем. Характерным примером могут являться Ашан или Магнит. Такие системы иногда называют “самописными”.
Слово “самописный” несет в себе некоторый уничижительный оттенок, намекая на домашнюю поделку и несерьезность. Мне больше нравится определение “собственная разработка”. Давайте понимать, что “промышленные системы” пишут точно такие же люди, у которых две руки и одна голова. И эти системы, как правило, имеют в своей основе ту же “собственную разработку”, которая получила крещение в какой-нибудь компании, а потом вышла на рынок.
Тема “промышленная система” против “собственной разработки” – это поле для еще одной “священной войны”. Оба подхода имеют свои преимущества и свои недостатки.
За один играет минимизация затрат на лицензии и поддержку, за других стоимость наращивания и поддержания ресурсов, занимающихся разработкой и эксплуатацией. В этом же аспекте можно рассуждать, что лучше: универсальность или специализация.
Сразу скажу, что разговор про риски связанные с “уходом ключевых игроков”, в моем понимании, практически эквиваленты для обоих случаев. Да, в случае “промышленного решения” замену возможно удастся подобрать чуть быстрее, но поверьте – это будет не слишком существенно, учитывая уровень кастомизации решения для серьезного бизнеса.
Вне зависимости от подхода, на мой взгляд, есть несколько ключевых моментов, от которых зависит насколько создаваемый и используемый в компании ИТ-продукт будет качественным. Говоря про качество, я подразумеваю адекватную автоматизацию бизнес-процессов, обеспечивающую конкурентоспособность бизнеса.
Итак, развивая ИТ-систему нужно озаботиться, как минимум, двумя вещами:
– наличием адекватного владельца продукта
– управлением внедрением изменений
Это именно то, что отличает серьезный системный подход от хаотичного шатания и является определяющим порог, за которым остается понятие “самописного”.
Для производителей программных продуктов “на продажу” это является просто необходимой частью их бизнес-процесса, в то время, как при внутрикорпоративной разработке этим вопросам зачастую не уделяется должного внимания. Обусловлено это тем, что им просто приходится учитывать достаточно разнородные требования, упаковывать их в единый контур и экономить на тиражировании и сопровождении внедрения.
В последнее время термин “владелец продукта” или “product owner” приобрел определенную популярность. Это связано с тем, что гибкие методологии управления проектами на базе Agile предусматривают такую роль. Владелец продукта определяет и транслирует общее видение развития продукта, агрегирует функциональные требования, планирует порядок их реализации, формируя его ценность.
Очень часто роль владельца продукта при внутрикорпоративной разработке размыта. Разработка часто движется по течению тупо перемалывая поток заявок от подразделений. На мой взгляд, это очень плохая парадигма, приводящая к тому, что появляется “китайский домик”, в котором могут быть достаточно комфортные комнаты, но в целом жизнь не доставляет удовольствия.
Будучи Директором по ИТ или Директором по развитию я всегда старался эту роль забрать на себя. Глубина погружения может быть разная, но формирование единого видения и задание стратегических ориентиров – это то, за что должен получать деньги человек управляющий развитием ИТ. Создание ИТ-системы – это тот проект, где ИТ-Директор должен быть владельцем продукта.
Мы уже говорили, что ИТ-система большой компании – это, как правило, зоопарк. У каждого из кусков могут быть свои владельцы. Где-то их называют руководителями проектов, где-то системными архитекторами. Для координации деятельности их удобно свести либо в одно подразделение, либо организовать совещательный орган. Только создание института владельцев продукта и организация их слаженной работы позволит избежать эффекта “китайского домика” и обеспечит формирование комфортной среды обитания пользователей.
Хочется акцентировать, что владельцем продукта не стоит делать бизнес-подразделение. Практически не бывает такого, что какая-то система работает только в интересах одного направления. Это как ТСЖ. Система должна учитывать интересы всех жителей, а для этого нужно знать потребности каждого и искать компромиссы. Заказчик и владелец продукта – это разные роли и не стоит их смешивать.
Работа с заказчиком – это одно из ключевых направлений деятельности владельца продукта. Невозможно культивировать ценность продукта в отрыве от заказчика. Умение формализовать, оцифровать, оценить хотелки на предмет адекватности, реализуемости и полезности – это тот набор компетенций владельца продукта без которого его деятельность не может быть эффективной. Вот почему глубокие знания предметной области, бизнес-процедур для ИТ-директора являются более важными, чем знания конкретных ИТ-платформ, технологий и решений.
Наличие внутреннего владельца продукта – обязательное условие, если вы хотите создать что-то стоящее. Если его нет, то другого варианта, как брать что-то на стороне и мириться с тем, что вам подсунули попросту нет.
Теперь поговорим об управлении внедрением изменений в ИТ-системы.
Вопрос достаточно комплексный и затрагивает такие темы как организацию среды разработки, обеспечение тестирования, подготовку и установку обновлений, разработку документации и обучающих материалов, проведение обучения и аттестации пользователей.
С технической точки зрения здесь все достаточно понятно. Есть масса описанных подходов и проверенных инструментов. Основным является то, что это нужно организовать системно: должны быть определены жесткие правила и отступать от них можно только в случае самой-самой острой необходимости.
Хотелось бы поделиться некоторыми моментами, с которыми приходилось сталкиваться и которые могут быть полезными.
– Ни одно тестирование не гарантирует, что на “боевых данных” все будет гладко.
– Как бы хорошо вы не прорабатывали, но пользователь всегда найдет вариант, который вы не предусмотрели.
– Два отлично работающих и оттестированных по отдельности модуля при совместной установке могут поломаться.
– Никогда не нужно проводить обновления в пятницу или перед праздниками.
– Даже изменение цвета или местоположения кнопки – это обновление.
– О любых изменениях нужно оповещать пользователей.
– Большинство пользователей не читают “Что нового?”
– Косяк обновления может вылезти не только на следующий день, но через месяц.
– Все сотрудники, чьи изменения вошли в релиз, должны быть на месте на следующий рабочий день.
– Обо всех странностях после обновления служба поддержки должна немедленно информировать владельца продукта.
Ну и чтобы текст не был таким сухим приведу два реальных случая, которые имели место во время моей работы в торговой сети Магнит.
Случай первый. Сеть уже насчитывала порядка 1500 магазинов. Каждый магазин имел свою независимую базу данных и система была построена так, что большинство обновлений требовало запуска ряда скриптов, который обеспечивала специальная программа “робот”. Эта программа была сама по себе достаточно уникальна для того времени, поскольку по сети этих “роботов” обеспечивалась передача данных между объектами и они же могли запускать автоматически достаточно большой набор сервисных процедур. Это было прогрессивно: запущенное по сети обновление автоматом устанавливалось практически на все объекты в течении пары дней (связь тогда была еще той), ну а там где возникали ошибки уже подключались люди. Такой подход позволял существенно экономить на обслуживании.
В один теплый пятничный вечер раздается телефонный звонок от руководителя службы технической поддержки и он докладывает, что у него шквал звонков из магазинов по поводу неработающих касс. Потом подсчитали, что за полчаса в поддержку поступило порядка 600 звонков. Кто знает, что для продуктового ритейла в магазинах у дома пятничный вечер – тот поймет.
Сразу сыграли тревогу. Крайнего нашли быстро. Ответственный сотрудник отдела сопровождения запустил обновление и по мере обработки обновления роботами магазинные кассы вставали. Потом выяснилось, что сотрудник запустил обновление пораньше, поскольку ему нужно было на день рождения к родственнику и он торопился.
Первое что сделали, это прервали обмен, чтобы те “роботы”, которые не успели получить обновление не повлияли на работу магазинов.
Дальше обнаружили, что кассы, работающие под правами директора магазина или товароведа продолжают работать. На пострадавшие магазины сразу отправили соответствующие инструкции, что с учетом малого количества касс сняло напряженность.
Параллельно шел разбор и поиск ошибки. Оказалось, что ошибка возникала на уровне предоставления прав между объектами базы данных. При формировании обновления в него попало два модуля, каждый из которых по отдельности был протестирован и к ним нареканий не было, но при совместной установке возникал конфликт. Нужно сказать, что на тестовой группе магазинов все прошло гладко именно по тому, что туда модули ставились по отдельности, а в плановое обновление их включили в одну сборку и не проверили. Исправление заняло буквально несколько секунд.
Случай неприятный, но очень поучительный. Из него было сделано очень много выводов и больше на моей памяти подобного не происходило.
Еще одна история связана с распределительными центрами. Мы как раз только начали заниматься разработкой собственной WMS-системы и много времени проводили на складе в Кропоткине.
Меня зовет руководитель РЦ и в панике говорит, что у них поменялась форма отборочного листа, отборщики отбирают неправильно и товар вместо штук неконтролируемо уходит блочками.
Штучной отборки в то время на РЦ было не много, но товар там был дорогой. И если у тебя вместо единицы уходит шесть при цене в 400 рублей – это точно не хорошо, особенно, если учесть, что на снабжении было магазинов под триста.
Начинаем разборки. Вопрос разработчику, который занимался печатью отборочных листов: “Что меняли?”. Сегодня ничего в листах не меняли. Но лист другой. В общем чудеса.
А за дверью триста мужиков, которые простаивают, а это хуже чем триста спартанцев. У тех хоть все понятно, а у этих горит заработок.
Поиски ничего не дают, все штатно. Ситуация накаляется.
В какой-то мере повезло, потому что в это же время в Кропоткине был руководитель РЦ из Энгельса. Поинтересовавшись в чем проблема и глянув на “новый” отборочный лист он сказал, что уже месяц по такому работает. На вопрос “как так? и как справился с проблемой?” он сказал, что ему админы передали, что вот такую новость прислали из Краснодара и теперь будет так. Он собрал народ, благо у него склад поменьше и народу тоже, проинструктировал по новому и все прошло гладко.
Оказалось, что “новый отборочный лист” был включен в тест, который проходил на РЦ Энгельс и поскольку никаких отзывов не последовало, то сопровождение посчитало, что все прошло отлично и включило его в плановую установку, которую робот и выполнил, когда смог. Когда причину нашли, то проблему устранили в несколько минут.
Надо сказать, что пока выясняли, скандал поднялся до самого верха и принял вид бросания телефонов и крепких выражений. Такое периодически случалось, но когда заслужили, тогда заслужили.
Минут через пятнадцать на вопрос “как обстановка?” руководитель отдела сопровождения отстучался в аську: “Все нормально. Заходил СН. С …. перешел на имена”.
И уж если вспомнился Сергей Николаевич Галицкий, то в контексте разговора о “владельцах продукта”, мне думается, успех Магнита связан именно с тем, что его собственник и руководитель отлично соответствовал этой роли применительно к торговой сети.
Глава 10
Как бороться с хроническим недостатком ресурсов
Самая распространенная претензия к ИТ-шникам это то, что они никогда не успевают. Всегда есть куча пожеланий от бизнеса, которые нужно было сделать еще вчера. Очередь заявок на доработки исчисляется десятками и сотнями. Любой менеджер при разговоре с руководителем обязательно сошлется, что ждет чего-нибудь от разработчиков и по этому что-то не успевает или не может сделать.
Такая ситуация вполне объяснима. Современный менеджмент – это в основном решение информационных задач. Для их решения постоянно требуются какие-то данные, которые нужно либо получить, либо изменить.
Людям приходит в голову масса идей. Каждая идея сразу кажется стоящей и требует своей просто немедленной реализации. При этом нормальная лень сразу ищет возможности переложить рутину на кого-нибудь и самые первые кто тут приходит на ум – это ИТ-шники. Пишем заявку и ждем пока нам ее не сделают. При этом у нас есть успокоительное для себя и отмазка для начальства.
Так и возникает дефицит ресурса. В большинстве случаев все упирается в программистов, которые заняты всегда. Мы уже говорили, что именно отсюда у подразделений возникает желание заиметь своего собственного программиста и я высказывал свое мнение, что идти этим путем ни в коем случае нельзя.
Казалось бы самый простой путь решения такой задачи – это набрать программистов. Если у бизнеса есть потребность и он “готов за это платить”, то почему бы и нет. Ну или не набрать, а привлечь на аутсорсинг. Давайте быстро наберем или привлечем и решим проблему за день-два.
К сожалению, в разработке так не работает. Это сложно воспринимается, поэтому я обычно привожу два примера. Нужно ли два человека, если требуется забить гвоздь? И если бетону для застывания требуется 28 дней, то как повлияет на это наличие 5 или 10 рабочих.
Сфера программирования не относится в тем областям, где в расчетах можно опираться на трудодни или человекомесяцы и линейно сокращать время за счет наращивания людей в команде.
Однажды, работая в Магните, мы решали одну достаточно несложную задачку в интересах транспортников. Вопрос касался регистрации прибытия/убытия автомобилей на торговую точку. Времена были древние, GPS было еще не в моде и мы делали отметки с использованием электронного ключа. Эта система была отработана на супервайзерах магазинов, сотрудниках безопасности, но у транспортников возникла проблема, поскольку в отличии от остальных, водители иногда попадали в интервал, когда система магазина была на обслуживании и база данных была недоступна для записи информации. И вроде бы чего там делать: давайте запишем куда-нибудь, а потом проверим доступность базы и перенесем данные. Только вот специалисты знают, что если делать по уму, то почему-то вылезет куча деталей: записать нужно туда, где просто так не достанешь, где точно никто не подменит; нужно обеспечить, чтобы информация не потерялась и не задублировалась – короче есть тысяча мелочей, с которыми нужно просто повозиться.
Задачу взяли в работу вчера и срок в три недели я обозначил руководителю Департамента транспорта в 3 недели. Расчет прост: неделя на разработку, неделя на тестирование и неделя на гарантированную раскатку обновления по всем торговым точкам. В районе обеда раздался шум в коридоре и ко мне в возбужденном состоянии залетел Галицкий вместе с Директором по транспорту.
– Как три недели? Там же нечего делать!
– А вот так. Разработка, тестирование, раскатка..
– Да я на свободном рынке сейчас найду команду, которая это за 3 дня сделает!
Короче тема закончилась спором на месячную зарплату при круглых глазах присутствовавших, оперативным написанием формализованного упрощенного технического задания (фактически перечня функциональных требований), которые уложились плотненько в полтора листа и тишиной на 3 недели. Кстати, успели мы на пару дней раньше – но это скорее повезло. Наличие ефрейторского запаса в один-два дня – это норма при озвучивании сроков.
Я был уверен, что никакая команда ничего нормального кардинально быстрее сделать не сможет. У нас программированием занимался один человек и потом ему помогали с тестированием и документированием.
Кстати, есть такой эффект, который описан в различной литературе, что оптимальным количеством людей к команде, которые работают над одной задачей пять плюс-минус два. Дальше начинаются проблемы на уровне организации взаимодействия и производительность падает.
Наращивать коллектив имеет смысл тогда, когда вы можете нарезать его на достаточно независимые команды, каждая из которых будет решать свою в какой-то степени изолированную задачу и при этом они не погрязнут в вопросах взаимодействия и интеграции.
Так сколько же программистов нужно держать? Это очень сложный вопрос. В моем понимании, ровно столько сколько вы сможете озадачить и еще немножко. А хороший ИТ-директор, поверьте может озадачить очень много.