Уже давно вы мечтали приобрести программный продукт, который решит многие проблемы вашего бизнеса. Вы работаете достаточно долгое время на рынке, есть успехи, вы расширяетесь, но чего-то не хватает. Эффективной аналитики, правильного прогнозирования, качественного контроля. И вот спустя какое-то время вы нашли программный продукт, провели тендер, сравнили аналоги и выбрали то, что вам «по карману».
Если вы собственник, то спланировав покупку, вы захотите, чтобы выбранная вами программа окупилась в короткий срок, и не стала очередным «дорогим калькулятором» для ваших сотрудников. Для этого, как только вы приняли решение о приобретении, стоит задуматься о процессе внедрения. Заметьте, не после покупки, а до того, как вы только приняли решение и спланировали бюджет.
Самое первое, о чем вы должны задуматься – это о «движке» процесса внедрения. Я называю «движком» специалиста, который будет владельцем всех процессов, связанных с внедрением приобретенного программного продукта. Этим специалистом должен быть не просто выбранным вами по занимаемой должности (например, начальник IT-отдела), или не сильно занятый в данный момент сотрудник, который более-менее понимает задачи, для приобретения которых вы купили программу. Во-первых, это должен быть специалист, который имеет опыт именно внедрения программ. Во-вторых, он должен понимать проблемы, которые должна решить данная программа. Он должен знать обо всех процессах внутри компании, которые связанны с решением задач при покупке программы. И конечно же, он должен «гореть». Под словом «гореть» я подразумеваю, что он должен как никто другой в компании понимать, что программа – это лучшее решение поставленных перед ним задач. Что при правильном внедрении компания получит эффективный инструмент, который облегчит работу многих, и в результате компания поднимется на ступень выше в своем развитии. И свой огонь этот внедренец должен уметь передавать не только топ-менеджерам, но и всем в компании.
Хочу оградить вас от распространенной ошибки, которую совершают собственники или топ-менеджеры, выбрав таким человеком IT-специалиста. Не спорю, любой IT-специалист разбирается в программах, знает все связи в них, сможет прописать дополнительный код. И все мы привыкли, что если IT-отдел нашел программный продукт, был ответственным за его приобретение и после покупки был связующим звеном в настройках связей, то и внедрением должен заниматься IT-специалист. Это неправильно!
Выбранный вами внедренец должен быть связующим звеном между разработчиком программы, IT-отделом и заказчиком программы внутри компании (в моем случае это, например, коммерческий отдел). И простыми словами должен понимать нужды заказчика программного продукта (коммерческого отдела), а после этого суметь правильно написать техническое задание для IT-отдела и разработчика программы. На своем опыте скажу, более правильно будет распределить задачу написания технического задания специалисту по внедрению. Расскажу на примере, почему.
Если написание технического задания на начальной стадии поручить IT-отделу, то специалисты отдела не всегда до конца понимают потребности коммерческого отдела. Например, какие показатели должны отображаться в планируемой программе, и на основании каких экономических формул данные показатели рассчитываются. Если написанием технического задания займется коммерческий отдел, то грубо говоря, разработчики, получив такое задание, будут переспрашивать по десять раз, пока не поймут, что хотят специалисты коммерческого отдела от программы в будущем. Ну и конечно, самый большой плюс в пользу написания технического задания специалистом по внедрению, который не относится ни к IT-отделу, ни к коммерческому подразделению, заключается в следующем. Ваш будущий специалист по внедрению, после того, как вы купите программу и обучите всех пользователей программы, будет ее сопровождать. И в процессе работы с программой у вас появятся потребности в новых доработках или функционалах программы. В таком случае специалист по внедрению, который знает программу с точки зрения ее функционала (связей внутри программы), а также экономические аспекты данной программы, без труда сможет написать новое техническое задание по доработке программы. Вы экономите время и деньги!
В заключение данной статьи скажу о том, что самый легкий путь для собственника или топ-менеджера – это обратиться к разработчикам приобретенной вами программы для ее внедрения. Во-первых, у них за плечами многолетний опыт, во-вторых, они знают все нюансы в данной программе, и изначально понимают, для чего она была придумана (ведь они ее разработали). Но чаще всего стоимость внедрения программного продукта от компании разработчика равна стоимости самой программы. Если вы купили программу за один миллион рублей, то тратить на ее внедрение еще один миллион рублей, по-моему, невыгодно. Лучше впоследствии придержать этот миллион на доработку программы, приобретения дополнительных функционалов.
Ищите «движки» внутри своей компании, они обязательно найдутся. Ведь сотрудники в курсе многих бизнес-процессов, и вы сэкономите время. Ведь специалист от компании разработчика в начале внедрения потратит минимум один месяц, чтобы изучить все ваши бизнес-процессы, изучить связи между отделами, и самое главное – выявить бизнес-цели, которые вы хотите достичь после приобретения программного продукта. А ваш сотрудник, работающий не один год в компании, без труда, в короткие сроки и эффективно справится с этими задачами. Но если у вас с персоналом совсем туго, то попробуйте поискать такого специалиста у ваших партнеров и одолжить его на время внедрения у них.
Интересно было бы почитать конкретные кейсы. Жду с нетерпением:)
Есть еще вариант: ИТ инфраструктуру отдать на аутсорсинг, так как процессы там типовые и есть куча стандартов. Тогда штатный ИТ специалист в классическом варианте, становится управляющим сервисов аутсорсера, а основной его функцией должно стать развитие бизнеса! Зная потребности бизнеса он и должен быть внедренцем новых решений. Те ИТ специалист, как специалист только в ИТ в этом смысле не нужен. Нужен специалист по развитию бизнеса, со знанием ИТ. Выгода от этого решения на порядок больше, чем от кажущейся экономии на внешнем подрядчике типовых услуг.
Рекомендую статью в продолжение моего варианта http://www.itworld.com/article/2927851/it-manageme... на английском языке, но очень актуально. Например, кейс сети из 1547 одежных бутиков в США: «ИТ специалисты выходят в торговый зал, общаются с клиентами, и наблюдают как люди реагируют на технологические новшества, также регулярно взаимодействуют с маркетингом и категорийными менеджерами, чтобы находить новые способы взаимодействия клиентов с компанией» (Eric Singleton, CIO at Chico's FAS, a $2.6 billion specialty retailer with 1,547 stores). Есть примеры и в России, но здесь очень хорошо описан тренд.
Передача it инфраструктуры на аутсорсинг дело интересно, но во первых (на собственном примере) передать лучше когда собственным it отделом не получается решить все возникающие задачи и вместо того чтобы искать замену существующим it специалистам или расширять отдел (нанимая дополнительного сотрудника). А во вторых моё мнение что контролирующим сотрудником должен быть не обязательно it специалист. Ну и в третьих, если расходы на заработную плату it отдела будут ниже того ценника, который выставит компания за услуги аутсорсинга не каждая компания (особенно в период спада) может себе этого позволить
Но мне кажется это ни как не связано с темой моей статьи о том кто должен заниматься внедрением в компании.
Как это не связано? Прямая связь!
Отдать it инфраструктура на аутсорсинг это параллельное дело. И по моему мнению я не вижу плюсов или минусов данного события (возможно они и будут, но это тема для отдельной статьи и отдельного обсуждения)
Алексей, спасибо за интересную тему, которую вы подняли в этой статье! И я полностью согласен с предложенным вариантом решения вопроса. Мне хотелось обратить внимание на интересный момент в связи с этой темой - с ролью ИТ специалиста в компании, о том, что она меняется и предложить еще один вариант решения. Верно, аутсорсинг может быть дороже, но это не из-за низкой зарплаты, а из-за отсутствия конкуренции среди аутсорсинга, что лишь вопрос времени. А вот штатный ИТ специалист, который становиться по сути бизнес-аналитиком - это гораздо более выгодная история, причем для всех и для компании и для специалиста. "Но если у вас с персоналом совсем туго, то попробуйте поискать такого специалиста у ваших партнеров и одолжить его на время внедрения у них" Те если стоит выбор кого взять со стороны - сотрудника внедряющей софт компании или сотрудника обслуживающего принтеры, то мне кажется ответ очевиден.
Максим согласен с Вами. Но хочу сделать небольшое дополнение насчёт штатного it специалиста. На моей практике сотрудник который имеет опыт внедрения различных программных продуктов, у которого есть отработанные методики на данную тему (даже без it образования), будет гораздо эффективнее it специалиста знающего специфику той или иной программы, имеющего it образование. Эффективность в плане внедрения новых программных продуктов
Максим, а у вас аналогичного материала для строительного рынка нет? Являясь сотрудником ламинат-сити и роспаркет ***ссылки удалены модератором***, ищу возможные пути оптимизации рабочего процесса. Возможно что-то найдете подходящее для меня, буду очень благодарен!
***Сообщение было отредактировано модератором. Нарушение пункта 7.1 Декларации Сообщества:
"Участникам Сообщества настоятельно рекомендуется:
1) воздерживаться от открытой саморекламы и рекламы своего бизнеса (в том числе недопустимо размещение на общих форумах или в блогах информации о вакансиях/мероприятиях компаний); "***
Три года назад начали разрабатывать своё ПО для внутренних потребностей обработки заявок на ремонты сетей связи. По мере роста компании система стала разрастаться и теперь там не только заявки, но и зарплата, учет тмц, срм и многое другое, столкунулись как раз с тем, что внутренние заказчики (комерсанты, финансисты, технари) не могут четко поставить задачу программистом а те не понимали бизнес процесс и это заходило в тупик. Тогда мы выбрали из своих сотрудников который мог бы выполнить функцию бизнес аналитика и смог бы писать граммотно техзадания для программиистов, оценивать затраты на доработки а заказчики могли оценить на сколько это оправдано и расставлять приоритеты. На сегодня точно можно подвести итоги что эксперимент оправдался, теперь программисты полностью в работе над граммотно поставленной задачей и не отвлекаются на понимание логики и запросы заказчиков.