Авторы: Андрей Подвезко, заместить генерального директора компании «АЛТИУС СОФТ»

Елена Астапенко, директор «Института методики управления»

Факторы, которые мешают клиенту получить нужное программное решение

Таблица к статье

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

Если сделать некоторое разделение проблем при реализации IT-проектов, то можно выделить четыре наиболее яркие категории:

  1. Проблемы технического характера,
  2. Проблемы «человеческого фактора»,
  3. Проблема «плохого» IT-решения,
  4. Проблема взаимодействия компании-заказчика и разработчика.

Технические проблемы

Здесь стоит говорить о нехватке системных ресурсов в автоматизируемой организации (или о несоответствии их требованиям программы):

  • компьютеров,

  • офисной сети,

  • средств связи.

Нередко в распоряжении компании-заказчика просто нет тех технических средств, которые позволили ли бы программе работать корректно. Банальная нехватка места на сервере – уже причина того, что IT-решение просто не получится использовать.

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

Как ни странно, но следующую сложность при реализации IT-проектов также стоит относить к категории технических проблем. Речь идёт о наличии и уровне подготовки IT-персонала компании-заказчика. Например, довольно часто системный администратор не знает специфики внедряемой программы и потому затрудняется её поддерживать. Вообще понятие «системный администратор» в последние 10-15 лет стали сильно упрощать. Сотрудник, который может сделать дефрагментацию диска, переустановить систему – уже гордо зовётся «системным администратором». На самом деле, роль этого специалиста в жизни компании, которая, к тому же, приняла решение об автоматизации деятельности, должна быть гораздо важнее. Это должен быть сильный специалист, с широким спектром знаний в области IT и способностью довольно быстро понимать специфику ПО. Применительно к отраслевым рынкам это очень важно.

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

Проблемы «Человеческого фактора»

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

  • нежелание перемен со стороны сотрудников автоматизируемой компании,

  • необходимость выполнять двойную работу сотрудниками автоматизируемой организации первое время,

  • непонимание того, что впоследствии программа будет реально помогать в работе,

  • страх незаменимых сотрудников стать ненужными,

  • невозможность обучения работе в программе, т.к. сотрудники компании могут быть людьми «старой закалки» (к примеру, пенсионного возраста).

Перемены пугают почти всегда. Хорошие ли они, плохие ли они – неважно. Новое, неизведанное, то, чего раньше никогда не было, обычно сотрудников вводит в какой-то ступор, хотя объективно поводов для беспокойства может и не быть. Как правило, распространённая точка зрения такова: «Мы и так много работали, хорошо себя чувствовали, получали заработную плату, а тут какая-то программа». Сюда же можно отнести и непонимание того, что программа далее будет реально помогать в работе, что она не бремя и не груз (во всяком случае, если это качественная отраслевая разработка), а, наоборот, помощник. В общем-то, здесь есть как мотивы просто несерьёзного отношения к делу или поверхностного понимания роли ПО в жизни компании, так и более серьёзные предпосылки для нежелания осваивать программу. Например, очень часто специализированное решение помогает выявить недобросовестного сотрудника, который работает так, как удобно ему, а не компании. Конечно, для него внедрение программы, которая призвана навести порядок, нежелательно.

Что касается выполнения двойной работы: здесь имеется в виду, что на первых порах внедрения программы сотрудникам необходимо организовывать свою работу по двум сценариям. А именно: по старому сценарию, который был принят в компании (например, продолжать заполнять электронные таблицы), и по новому, который заложен в программу.

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

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

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

Сложность решения проблем, связанных с человеческим фактором, можно отнести к категории средних. Решается данная группа проблем путём проведения разъяснительной работы со стороны руководства и разработчика. При этом наличие таких проблем внедрению программы мешает сильно. Поскольку общее настроение коллектива, халатность и понимание того, что руководство «ничего не сделает», очень расслабляет и на работу в программе, конечно, не настраивает.

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

Проблема «плохого» IT-решения

Компьютерные программы, так же, как и еда, одежда, обувь, техника бывают плохими – это правда. Здесь важно понимать, что универсального решения не бывает, решения должны быть отраслевыми. То есть, если отрасль строительная – значит программа должна быть ориентирована на нужды строительных компаний. Многие разработчики же хотят охватить рынок по максимуму, разработав единое программное решение, которое и строительной компании и медицинской, будет, что называется, впору. Так не бывает. Во всяком случае, если речь идёт действительно о средстве автоматизации, ERP-системе, а не о текстовом редакторе, например. Решается такая проблема просто – путём внедрения специализированного отраслевого решения, а не программы «для всех типов компаний». Впрочем, внедрению какой бы то ни было программы проблема данного свойства сильно не мешает. Со временем доработать программу под нужды организации возможно, если заказчик согласен ждать месяцы и даже годы и платить за это.

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

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

Проблема взаимодействия компании-заказчика и разработчика

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

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

Расплывчатая стоимость системы тоже является камнем преткновения между компанией-разработчиком IT-проекта и компанией-заказчиком. Дело в том, что немногие компании-разработчики могут обеспечить пакетность услуг, обозначить конкретную стоимость системы и услуг по её внедрению (в процессе внедрения могут быть выявлены различные нюансы в построении бизнес-процессов компании-заказчика). На отраслевом рынке B2B – это явление, по сути, стандартное. Ответить на вопрос: «Сколько это стоит?» не могут многие разработчики. Дело в том, что иногда даже в готовое решение заказчик хочет добавить новый функционал, который будет ориентирован на специфику его компании. Соответственно, если такая возможность у исполнителя есть, то это будет расцениваться как дополнительная работа. Сложность решения этой проблемы довольно низкая. Достаточно прийти к компромиссному решению между заказчиком и исполнителем (поговорить о скидках, рассрочках платежей и так далее). Внедрению же она мешает сильно, т.к. из-за минимальных недоговорённостей процесс внедрения может быть прерван на полпути.

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