В чем разница между «дорогим калькулятором» и эффективным IT-решением

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

В данной статье я расскажу, как не допустить того, чтобы купленный программный продукт стал «дорогим калькулятором», и деньги, потраченные на его приобретение, все-таки окупились.

1. Проводите пилотный проект

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

2. Поручайте «пилот» поставщику IT-решения

После того как вы решите начать пилотный проект, обязательно задумайтесь над тем, кто будет его проводить. Если поставщик вместе с пилотным проектом предлагает вам внедрение программного продукта, не жалейте на это денежных средств. Если вы решите самостоятельно организовать «пилот», то вероятность успеха скорее всего будет минимальной. Ваш собственный IT-менеджер, которому вы поручите эту работу, не сможет полностью учесть все особенности нового решения. Он будет руководствоваться стандартами и методами, к которым привык. А если «пилотом» займутся специалисты по соответствующему IT-продукту, они будут руководствоваться новыми стандартами и методами, что позволит им полнее использовать возможности программного обеспечения.

3. Планируйте внедрение программного продукта

Пилотный проект закончился, вы получили подробную аналитическую записку по результатам внедрения «пилота» и пришли к выводу, что данная программа подходит для решения поставленных вами задач. Вы планируете закупить лицензии и само программное обеспечение. Но если вы еще в начале проекта не спланируете процесс внедрения программы (своими силами, с помощью IT-компании или фрилансера), то со временем она точно станет «дорогим калькулятором». Да, она покажется всем интересной, да с ее помощью можно будет получить много интересующих вас показателей. Но окажется, что ваши сотрудники либо привыкли работать в старых программах, либо им просто лень вникать и изучать новую программу.

4. Обозначайте бизнес-цели проекта

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

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

5. Не экономьте на обучении и тестировании сотрудников

Обучение специалистов работе в купленной программе является не менее важной частью процесса внедрения. Обратите на нее особое внимание. Чаще всего, продав программное обеспечение, IT-компания бесплатно проводит несколько сеансов удаленного обучения. В ходе этих занятий она вкратце показывает, как пользоваться теми или иными отчетами, формируемыми в программе. Практика показывает: после таких занятий в головах сотрудников остается всего 10-15% показанного им материала. Поэтому не ограничивайтесь бесплатными демонстрациями и не жалейте средств на организацию полноценного процесса обучения.

Обучение сотрудников следует поручить специалисту IT-компании. Желательно разбить на несколько этапов:

  • Первоначальное обучение сразу после приобретения программы
  • Дополнительное обучение в каждом подразделении (таких занятий должно быть не менее семи-десяти в течение одного месяца)
  • Персональное обучение топ-менеджеров и собственников компании.

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

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

Таким образом, следуя всем вышеперечисленным рекомендациям, вы не позволите превратить новое программное обеспечение в «дорогой калькулятор». И инвестиции в него окупятся сполна.

Расскажите коллегам:
Комментарии
Менеджер группы продуктов, Томск

Статья написано хорошим академическим языком. Видно, что автор глубоко в теме, возразить нечего. Но, блин, не интересно читать. Мы же испорчены Котлером и Кови. Мы хотим интересных случаев из жизни. Нам подавай увлекательные кейсы. Нам нравятся цифры - статистика. Я ни сколько не умоляю ценность статьи, но учебник читать скучно. Жду конкретные кейсы.

Менеджер, Украина
Андрей Кузин пишет:
Статья написано хорошим академическим языком.

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

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

Вот такая была оценка эффективности технологического процесса до внедрения программного продукта (Е1), а вот эффективность после внедрения (Е2) :-)

Директор по развитию, Кемерово

Андрей, спасибо за то что вносите такое хорошее предложение (которое в принципе стандартное, но правильное) в процесс написания статьи. Впредь учту, и порадую вас интересными фактами из моей практики и свежими практическими решениями (с примерами показателей "до" и "после") в области внедрения it-продуктов.

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

Игорь, переформулируйте, а то получилось процессы на процессы.

Менеджер, Украина
Андрей Кузин пишет:
Игорь, переформулируйте, а то получилось процессы на процессы.

Андрей, когда мы пытаемся что-то улучшить, в рамках предприятия, то должны выделить систему, эффективность процессов которой нас интересует. В основе любой системы лежит технологический процесс. Признаком базового технологического процесса является его ресурсоёмкость. Для производственного предприятия это может быть энергопотребляющий процесс, для торгового процесса - финансопотребляющий и т.д.

Для управления технологическими процессами служат процессы управления. Сюда входит сбор, обработка и использование данных. Так вот, оценить эффективность можно только технологического процесса. Программные продукты могут повысить качество управления и повлиять на эффективность технологических процессов.

Поэтому оценить вклад программного продукта (изменения процессов управления), можно только посредством оценки его влияния на результаты функционирования (эффективности) технологического процесса :-)

Руководитель, Москва

Мне понравилась статья, и неважно в данном случае, каким языком она написана. Хорошим языком написана:)

Добавила бы следующее: постановка и формулирование целей и задач ДО этапа выбора IT решения, чтобы четко понимать - зачем его покупать? Удивитесь, сколько компаний этого не делает по разным, часто по традиционным российским причинам:( Второй момент. Необходимо "внедрение" с участием представителей основных бизнес-направлений пользователей (особенно важно, если речь идет о портале - в этом случае требования пользователей должны быть собраны также и на нулевом этапе, т.е. до покупки технологии). Внедрение (пилота в том числе) должно проходить с учетом кривой изменений (страх, отрицание, любопытство, интерес, лидерство). На разных этапах проводятся разные PR и обучающие мероприятия. Поэтому даже на этапе внедрения "пилота" в этом процессе должны также участвовать и представители покупающей стороны.

Текст автора об обучении и последующем вовлечении пользователей в процесс развития продукта - очень важно! И, кстати, неудовлетворение IT продуктами в компаниях чаще всего происходит именно по причине недостаточно продуманных и плохо проведенных PR и обучающих мероприятий.

Директор по развитию, Кемерово

Согласен, Внедрение как пилотного проекта так и полноценного проекта конечно должно происходить с участием представителей основных бизнес-направлений пользователей (в пилотном проекте на моей практике это чаще всего руководители подразделений). Они автоматически становятся "инициативной группой", которая дальше будет нести "идеологию в массы". Эти же самые участники изначально и участвуют в очень важном процессе постановки бизнес задачи как пилотного проекта так и полноценного проекта.

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

Насчёт обучения. Приведу пример. Компания решила начать пилотный проект аналитической программы, но решила провести её самостоятельно. Пилотный проект был рассчитан на 1 месяц. Но по истечении 2х недель, после общения с начальником it отдела стало понятно, что при самостоятельном внедрении пилотного проекта возникло много трудностей. Двух обучений от разработчика it решения не хватило, обучающиеся усвоили максимум 10% от той информации, которая им предоставлялась на обучении. Внедрение началось без определения бизнес цели пилотного проекта (и конечно без определения показателей для её достижения). Поэтому постепенно основные участники утратили интерес к трестируемой программе. Но после настойчивых переговоров они приняли правильное решение, заказали внедрение пилотного проекта у разработчика. И всего за две недели (оставшиеся до окончания действия тестовых лицензий) внедрение прошло на ура! Две недели малый срок чтобы достигнуть весомых изменений в определенных показателях, но все же основные участники пилотного проекта утвердив бизнес цель и пройдя "ускоренное" дополнительное обучение увидели эффективность работы в данном it решении. Но если говорить о явном эффекте (примеры), то после двух недель пилотного проекта начался процесс наведениях порядка в товарных карточках (к примеру в одной товарной группе было найдено около 15% "мертвых карточек", которые должны быть закрыты на магазинах).

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
3
Евгений Равич
Хороший пример конспирологии. Есть реальные примеры? Просьба заодно уточнить, что такое "не понр...
Все дискуссии
HR-новости
Сотрудники не готовы отказаться от гибрида даже за повышение зарплаты

При этом 47% работодателей все еще считают такой формат работы привилегией, а не данностью.

Спрос на операторов call-центра в продажах вырос в 3,5 раза

В целом за первый квартал 2024 года по России количество вакансий в продажах выросло на 26% за год.

53% компаний возьмут студентов и подростков на летнюю подработку

За год интерес к такой практике вырос на 8%.

Россиян ждет шестидневная рабочая неделя

Шестидневной эта неделя оказалась за счет переноса выходного дня на понедельник – 29 апреля – для того, чтобы отдыхать россияне могли без перерыва.