Как не надо тестировать программы для бизнеса
По статистике от 50 до 80% попыток внедрения ERP-систем терпят неудачу из-за ошибок в момент тестирования и внедрения. А ведь возможности подобных программ позволяют сделать рабочие процессы прозрачными и структурированными. Вот только от штатных айтишников в этот момент звучит: «нет времени», «не хватает мощностей», «мы еще не разобрались», «у нас сложно это настроить».
А ведь еще есть и компании, ИТ-услуги которым оказываются аутсорсерами. Подобных компаний в России по оценкам экспертов более 60%. В таком случае объем услуг ограничен договором, а за внедрение и проверку нового ПО придется дополнительно заплатить.
У выполнения современных требований к автоматизации бизнеса есть свои нюансы. На примере программы для контроля времени работы за компьютером разберемся с заблуждениями, которые не дают осваивать полезные продукты.
Часто менеджмент компании считает, что айтишники сведущи во всех областях, которые так или иначе связаны с программами или комплектующими. Это не так. Не существует универсальных специалистов, которые одинаково хороши во всем.
Допустим, руководство приняло решение опробовать работу софта собственными силами. Чтобы установить, настроить и понять, как работает программа, сотруднику придется потратить кучу времени и сначала самому разобраться во всех тонкостях. При этом ИТ-специалист может не до конца осознавать назначение сервиса. Поэтому спешить он не станет. С одной стороны — всегда есть текущая работа, с другой — новое ПО расширяет круг ответственности.
Такой подход невыгоден компании — тратить время сотрудника всегда лучше с пользой. Здесь же польза призрачна. И есть простой выход: заказать у разработчика ПО пилотный проект.
В идеале схема работы такая: внешние специалисты вместе с ИТ-отделом выполняют все работы, попутно объясняя техническую сторону вопроса. Экономится время, штатные специалисты получают всю нужную информацию от первоисточника. Еще один плюс — представители поставщика научат работе в программе.
И снова мимо. Оценить удобство и полезность нового ПО могут только его непосредственные пользователи. Например, внедряется программа для бухгалтерии. О ее достоинствах или недостатках не может рассказать человек, который далек от счетов, ведомостей и деклараций. То же с любым специализированным софтом.
Рассмотрим пример с тестированием программы для отслеживания времени работы за компьютером. Эффективность работы ИТ-отдела непросто оценить. Сотрудники любят пользоваться страшной терминологией и доносить до руководства, что очень загружены работой. Теперь представим, что им предложили опробовать ПО, которое покажет, сколько времени они тратят на работу, а сколько времени сидят на форумах, в соцсетях или занимаются чем-то еще. Это точно не в их интересах, так зачем напрягаться?
В нашем примере участие в тестировании должны принимать руководители отделов, сотрудники безопасности, специалисты по персоналу — категория людей, которая контролирует процессы в компании и нуждается в данных о происходящем на рабочих местах.
Разработчик может провести обучение и демонстрацию возможностей. Тогда будет проще вникнуть в особенности программы и эффективно ею пользоваться. В таком режиме оценка продукта будет объективнее, не возникнет проблем из-за незнания.
В ведение отдела ИТ стоит отдать контроль технических параметров системы: выдерживает ли сервер нагрузки, корректно ли работает сеть, хватает ли мощности оборудования.
Справедливо, но не всегда. Если программа напрямую не влияет на ход бизнес-процессов (выставление счетов, управление продажами), не затрагивает важные данные, но требует масштабную среду для тестирования, тогда ее можно разворачивать сразу в реальных условиях.
Например, ПО выполняет контроль времени работы за компьютером и никак не может навредить работе компании. А для оценки потребуются данные с многих рабочих мест. Моделировать такие условия затратно, поэтому испытания разумнее проводить «в бою».
Итак, тестовый период подошел к концу, пора принимать решение. Кто возьмет на себя ответственность? Если все тестирование ограничивалось рамками ИТ-отдела, то об объективных итогах говорить нельзя. Нет понимания, насколько продукт пригоден для целей бизнеса.
Взвешенное решение лучше принимать сообща, изучив все стороны: профессиональную, техническую и материальную. Если программа помогла скоординировать работу сотрудников и повысить производительность, то с точки зрения руководителя она нужна. При этом может быть так, что мощности оборудования с трудом справляются с новой нагрузкой, и тогда ИТ будут убеждены, что этот софт компании не подходит. Есть еще и окупаемость — продукт должен быть выгодным.
Все это обсуждается и просчитывается. Если есть вопросы к разработчикам, их тоже нужно привлекать. Если в целом программа понравилась, но компании нужны специфические формы отчетов или другие функции, которых нет в базовом релизе, это можно решить с производителем ПО.
Получается, выбор программ для бизнеса зависит не только от самих продуктов, а еще и от того, как проводится тестирование. Исключайте необъективность, обращайтесь к специалистам и разработчикам. Каждый в этом процессе должен заниматься своим делом.
Полное или частичное копирование материалов возможно только при указании ссылки на источник — сайт www.infowatch.ru или на страницу с исходной информацией