Мнение эксперта: Олег Вайнберг, IT-директор сети "Кей"
— Олег, какова роль информационных систем в розничном бизнесе?
— Розничный бизнес – он очень разный. Ларек – тоже розничный бизнес. Однако, если отбросить ларьки, розница очень давно использует информационные системы. От простейших таблиц в Excel и до SAP. Все определяется количеством номенклатурных единиц и оборотом. Зачастую, вполне достаточно с утра распечатать и раздать продавцам состояние склада, а вечером, с тех же листочков, занести данные о продажах. При небольшом обороте и небольшом ассортименте это отлично работает. Но и это – информационная система. Следующий шаг – когда число продаж растет настолько, что продавец не успевает делать отметки или ассортимент таков, что продавец не успевает найти нужную строчку. Надо «автоматизироваться». Альтернатива – работать «по остаткам». По результатам работы смены «снимаются остатки» и сверяются отсутствующие товары и появившиеся деньги. Система трудоемкая, но работоспособная. Но снимать остатки трудоемко и обычно появляется 1С в какой-нибудь ипостаси. Это тоже информационная система. Иногда вместо 1С появляется что-то «самописное».
Следующий шаг – подключение к системе кассы. И вот в этот момент бизнес попадает на крючок информационных систем. Потому что при отключении системы ИТ, бизнес просто останавливается. Даже если предпринята масса усилий и все задублировано и может работать автономно. Потому что всегда найдется точка отказа. А персонал уже просто отвык работать руками и головой. «А почему не сделали переучет? – А сервер был отключен! А бумагу и карандаш найти не смогли?! Ааааа…. это как?». Начиная с этой минуты, роль информационной системы в розничном бизнесе очень проста. Если система спроектирована очень грамотно – ее выключение сильно затрудняет бизнес первые несколько часов и делает его невозможным примерно через сутки. Если система спроектирована плохо – продажи останавливаются в ту же секунду.
— Как изменилось отношение владельцев и топ-менеджеров розничных компаний к автоматизации за последние год-два?
— Отношение к ИТ? Как к неизбежному злу. Рост заработной платы вообще и усилия государства по выводу ее из тени, привели к тому, что 1000 евровый компьютер стоит намного дешевле человека и окупается за пару месяцев. Соответственно, если можно поставить 2 компьютера и убрать одного человека – именно так и поступают. Второй момент – падение цен на средства ИТ. Отличный наладонный компьютер со сканером, системой беспроводной связи и т.д. стоит теперь порядка 1500 евро против 3-5 тысяч 2 года назад. Поэтому степень автоматизации розничных компаний стремительно растет. В розничных компаниях очень сильно выросли затраты на ИТ. Соответственно – сильно возросли требования. Нужна не просто информация – нужна аналитическая информация. Требуется не просто «внедрение». Требуется реальное увеличение производительности труда. Или радикальное улучшение обслуживания покупателей и рост оборотов.
— Какие первоочередные цели преследуют ритейлеры на практике, автоматизируя свой бизнес?
— Как я уже говорил, ритейл автоматизирован изначально. На мой взгляд, нет смысла говорить об автоматизации. Есть смысл говорить о реавтоматизации. Поэтому первоочередная цель – не уронить бизнес. Если об этом забывают – быть беде. Появляются воздушные замки, останавливаются отгрузки. Иногда бизнес просто не переживает «внедрения».
Вторая цель – улучшить протекание бизнес-процессов. Иногда видоизменить их. Результатом должно стать увеличение целевого показателя. Какого? Смотря, что автоматизируем. Пропускной способности кассы или магазина, скорости приемки или отгрузки товара центром распределения,…
Третья цель – получение удобной аналитической информации с возможностью агрегирования и детализации.
— Кто обычно является «заказчиком» проекта внедрения информационной системы? А кто должен быть?
— Есть понятия «спонсор проекта» и «менеджер проекта». Различаются они примерно как «покупатель» и «потребитель». «Заказчиком», то есть спонсором проекта должно выступать первое лицо компании. Это обязательное условие. На практике именно так и происходит, поскольку стоимость автоматизации легко может перевалить и за полмиллиона и за 5 миллионов евро. К сожалению, нередки случаи, когда спонсор проекта, желая точно знать, куда тратятся эти безумные деньги, назначает себя менеджером проекта. Управление проектом обычно занимает до 60% рабочего времени. Из этого времени – 90% просто рутинные операции по организации встреч ключевых пользователей, распределении ролей, отслеживании этапов и прочего «пинания в зад». Поскольку первое лицо компании обычно не имеет столько свободного времени и давно отвыкло от технической работы, проект плавно заваливается.
— Как правильно сформировать команду внедрения со стороны заказчика и исполнителя? А как оно происходит на практике?
— Как правильно – не знаю. Но знаю, как надо (улыбается). Есть некие теоретические выкладки, с ними можно познакомиться в учебниках по менеджменту. Должен быть спонсор проекта и это должно быть первое лицо компании. Должен быть менеджер проекта со стороны заказчика. На время проекта его можно считать мертвым. Или полумертвым. Потому что порядка 60% своего времени он отдаст проекту. Есть ключевые пользователи. Кого причислить к таковым – вопрос баланса на острие дела и политиканства. Ключевые пользователи – это те, кто может оказать на проект значительное влияние. И на кого проект, в свою очередь, окажет значительное влияние. Но хорошо бы, чтобы этот пользователь действительно владел знаниями о бизнес-процессах, которые подлежат автоматизации. Обычно ключевые пользователи – функциональные директора: коммерческий, финансовый,… Если проект после окончания будет поддерживаться силами своего отдела ИТ, нужна проектная команда своих специалистов.
Со стороны исполнителя команда должна быть сформирована похожим образом. Менеджер проекта, аналитики, программисты.
Я участвовал в успешном проекте внедрения MS Axapta. Команда разработчиков состояла из руководителя (менеджера) проекта, нескольких аналитиков, которые проводили интервью с пользователями и обрабатывали их «хотелки» для программистов, и нескольких программистов.
Команда заказчика состояла из спонсора (генерального директора), менеджера проекта со стороны заказчика (ИТ директора), функциональных директоров, привлекаемых по необходимости, и команды ИТ-поддержки (серверный специалист, администратор базы данных и два программиста), которая потом должна была взять на себя поддержку системы. Ресурсы команды ИТ поддержки использовались разработчиком, что несколько снизило стоимость проекта и позволила ИТ команде получить необходимое обучение в процессе работы.
— Какие трудности возникают в ходе организационной подготовки проекта, в т.ч. при создании «проектного офиса»? Как их избежать?
— Если платформа, на которой будет выполняться проект, выбрана и выбран исполнитель, то необходимо решить массу рабочих вопросов.
Рабочая группа нуждается в отдельном помещении, достаточно просторном, чтобы вместить 6-8 человек. Помещение должно быть комфортным, оборудовано мебелью, локальной сетью с выходом в Интернет и ограниченным доступом в сеть предприятия. Поскольку сотрудники проектной группы обладают закрытой информацией, например, подробным описанием всех бизнес-процессов, эта локальная сеть должна быть защищена извне и изнутри. Может оказаться, что программное обеспечение и структура этой сети противоречит корпоративным стандартам предприятия. К примеру, предприятие использует сеть на основе серверов Novell или Linux, а проектная группа использует сеть Microsoft. Кроме того, необходимо обеспечить возможность пользоваться отдельным помещением для проведения совещаний, рабочих встреч и интервью. Необходимо снабдить аналитиков перечнем ключевых пользователей с телефонами, e-mail и описанием областей компетентности. Необходимо установить регламент интервью, рабочих встреч и коммуникаций между представителем заказчика и подрядчика.
— Какие существуют способы прогнозирования эффективности проекта? Используются ли они на практике?
— В системе показателей Dupont существует показатель ROI, то есть отдача от инвестиций. В принципе, это универсальный показатель и он может быть использован. Однако, я не знаю ни одного примера практического использования показателей эффективности ИТ проектов. И вот почему. Эффективность – это по определению, показатель отношения выходов к входам в каком-то процессе. Вложил 100 убитых енотов, получил 200. Эффективность на лицо. Однако, при оценке эффективности проекта, необходимо сравнивать 2 величины.
Мы вложили средства и получили работающую систему;
Мы не стали вкладывать средства и продолжаем жить как жили.
К сожалению, очень трудно определить, что стало бы с бизнесом, если бы проект не был проведен. За исключением «патологической страсти к автоматизации», которая характерна для госструктур, проект проводится тогда, когда «жить как жили» уже не получается. Таким образом, приходится заниматься качественными оценками. Мы потратили миллион долларов и вроде как фирма нормально работает. Можно ли было не тратить этих денег? И можно было бы вложить их в другие проекты? Бюджет ИТ проекта сопоставим с бюджетом проекта открытия небольшого магазина. Какой из этих проектов даст большую отдачу? И в какие сроки?
Таким образом, для оценки эффективности проекта, необходимо, прежде всего, хорошо сформулировать цель. Я знаю фирму, которая потратила на внедрение SAP порядка 8 миллионов евро. В качестве результатов были названы повышение удовлетворенности клиентов и повышение капитализации компании. Если отбросить первую часть (я знаю массу способов удовлетворить клиентов дешевле, чем за 8 миллионов евро), то остается повышение капитализации. Если это и было целью – то можно попробовать подсчитать ROI. До внедрения компания оценивалась в X, после – в Y, затраты составили Z. А вот если целью было увеличить оборот? Или снизить издержки? И как быть, если кроме декларируемых целей есть еще и недекларируемые?
— Какие существуют подходы при расчете стоимости (бюджета) проекта внедрения и поддержки информационной системы? Что Вы используете чаще и почему?
— Прежде всего, давайте определимся с целями заказчика и исполнителя. Часть из этих целей совпадает, часть, возможно, противоречит друг другу.
Вероятные цели заказчика:
Получить работающую систему, удовлетворяющую всем потребностям бизнеса,
Заплатить за это как можно меньшую цену,
Провести изменения в максимально сжатые сроки, при этом по возможности ни чего не меняя,
Обучить свой персонал.
Вероятные цели исполнителя:
Получить работающую систему, удовлетворяющую техническому заданию и требованиям заказчика,
Получить за это максимально возможную сумму,
Провести изменения в сжатые сроки,
Увеличить квалификацию своих разработчиков.
Разумеется, перечень и не полон и спорен. Но очевидно, что часть целей совпадает, часть лежит в разных плоскостях, а часть противоречит друг другу. Требуется тщательный анализ целей, проработка всех спорных моментов и поиск компромиссов. Очевидно, что обе стороны заинтересованы в успешном завершении проекта. Интерес заказчика очевиден, интерес исполнителя – получение «премиального» заказчика, к которому можно приводить потенциальных клиентов, показывать, как все здорово и получать новые заказы.
Что же до желания заказчика заплатить как можно меньше, а исполнителя – заработать как можно больше, то это скорее вопрос доверия. Услуги, в которых невозможно до ее оказания определить, с каким качеством она будет оказана, так и называются – доверительные услуги. Это услуги врачей, адвокатов,… и программистов.
Есть два основных подхода к формированию бюджета. Фиксированная стоимость и повременная оплата. Существует масса апологетов обоих подходов. Причем оперируют они одним и тем же аргументом: «наш подход намного дешевле». Давайте попробуем разобраться. Фиксированная цена подразумевает, что на начальном этапе оговаривается, что именно надо сделать и сколько это будет стоить. Казалось бы – предельно честный подход. Объем работы понятен, цена тоже. Устраивай тендер и вперед. Правда? Нет, не правда. На момент заключения договора, да и даже после создания технического задания, не до конца понятно, что именно должно получиться. Как раз объем работ остается совершенно неопределенным. Заказчик и исполнитель говорят немного на разных языках, моменты, совершенно очевидные для заказчика, вовсе неочевидны для исполнителя и наоборот. В общем, здравомыслящий исполнитель уверенно прибавляет к оценке проекта еще процентов 15. Но и это не спасает и каждый новый «затык» вызывает взрыв эмоций на тему «этого не было в ТЗ и за это придется платить отдельно». Отсюда перерасход бюджета проекта и масса конфликтов.
Второй вариант – оплата времени. На начальном этапе рамочно оговаривается, сколько примерно средств потребуется. А дальше любые доработки и изменения расцениваются в часах работы исполнителей. А заказчик, получив расценный блок, решает, что именно он будет делать. А без чего пока обойдется. Что сделано, за то и заплатили. Справедливо? Разумеется. Если не учитывать тот факт, что расценку делает исполнитель, проверить ее справедливость невозможно, взять альтернативного исполнителя на «кусочек» проекта тоже не получится.
Так что повторяю, это просто вопрос доверия. В конце концов, в успехе заинтересованы все.
