Иногда удивляет, насколько взвешенно многие подходят к личным задачам и насколько хаотично – к рабочим. Задачи берем довольно конкретные, по выбору чего-то значимого. К первым (личным) в данном случае можно отнести практически все, что угодно – выбор машины или квартиры, ноутбука или места для отпуска. Ко вторым (рабочим) – тоже многое, в том числе и выбор корпоративного программного обеспечения (ПО) для совместной работы. Забегая вперед отмечу, что написанное можно рассматривать почти для любого корпоративного ПО. Но я по опыту имею ввиду электронный документооборот, а также системы для управления проектами, процессами, задачами и комплексные решения на стыке указанных.
Как не надо выбирать и внедрять программное обеспечение
С середины 2000-х я наблюдаю как происходит выбор корпоративного ПО в компаниях самых различных отраслей, размеров и зрелости управления. Про это я могу рассказывать долго, но что особенно важно – ситуация с подходом не улучшается, а ухудшается. Занятно, что чем больше IT-решений представлено на рынке, тем менее структурированный подход к выбору решений у заказчиков. К примеру, часто пытаются использовать не более подходящее, а то, что больше на слуху. Часто выбор осуществляется импульсивно. Часто экономят там, где экономить нельзя. Я не уверен, что дело именно в количестве возможного ПО (хотя и это само по себе тоже важно – широкий выбор, как известно, балует). Думаю, что проблема шире.
Например, играет роль и экономическая ситуация – нежелание, а в некоторых случаях и невозможность мыслить на среднесрочную и долгосрочную перспективу: «Выберем быстренько что-то, какой там еще комплексный подход». В перечень проблем можно отнести и все более агрессивный маркетинг со стороны разработчиков. Очевидная проблема – за красивой оболочкой и громкими словами часто скрывается меньше, чем ожидает заказчик. А иногда вообще не то, что он ожидает. Как бы странно это не звучало, но из практики знаю случаи выбора заказчиком CRM (система управления контактами с клиентами) вместо СЭД (система электронного документооборота). Или выбора системы управления задачами, когда была актуальна мощная система управления процессами (обратные ситуации тоже не редкость). И не совсем очевидный, но не менее важный момент: заказчик все чаще ожидает, что выбор и собственно внедрение не потребуют никаких усилий, что система заработает, как надо, сама собой.
Сложно сказать, кто в этом виноват. Возможно, маркетинг, который убеждает: «Купите у нас – жизнь станет сказкой», умалчивая, что внедрение и поддержка ПО тоже трабует затрат. Возможно, первым эту историю начал Стив Джобс. И я, кстати, не шучу. Неоднократно сталкивался на клиентских встречах с высказываниями в духе: «Вот iPhone, мне тут все понятно сразу, а в корпоративных системах нужно долго разбираться». Да, согласен. Но не надо подменять понятия, давайте все-таки различать потребительские потребности и бизнес. Особенность первого: унификация возможностей, упрощение и стандартизация. Особенность второго: уникальность, способность и необходимость постоянно меняться и развиваться. Эти особенности можно сочетать, но наивно думать, что эта задача решиться сама собой и мгновенно.
Как сделать так, чтобы и уникальность сохранилась, и корпоративное ПО было выбрано корректно? Ответ на этот вопрос я получил очень давно, когда один мой товарищ показал мне курс продавцов одного из именитых западных поставщиков программного обеспечения. Там красным маркером были отмечены несколько ключевых вопросов, ответы на которые критичны для продажи:
- Требования.
- Бюджет.
- Ответственный.
- Сроки.
- Стадия.
Это было десять лет назад, и сейчас вряд ли для кого из продавцов станет откровением. Но со временем пришло другое понимание – владеть такой информации крайне важно не только поставщику, но и заказчику. Что дает эта информация продавцу? Расширенную карточку в CRM и понимание плана продаж – на самом деле ему больше и не нужно. Что дает эта информация заказчику? Гораздо больше: контроль ситуации, адекватное планирование, и самое главное – снижение вероятности ошибок. Пройдемся по каждому пункту отдельно.
1.Требования к поставщикам и ПО
Часто заказчик пытается выставлять требования к возможностям ПО (причем по принципу «чем больше, тем лучше»). Грубо говоря, сотрудники заказчика пытаются предположить, как будет работать программный интерфейс. Это фундаментальная ошибка. Лучше так не делать, даже если у вас бесконечный бюджет и собственные разработчики. Начинать нужно с другой стороны – с описания процессов компании, с определения ответственных за эти процессы. Иначе вы надолго завязнете в обсуждении кнопок.
Нет описания процессов? Необязательно бежать изучать BPMN (можно вообще не знать, что такое Business Process Model and Notation, методология моделирования бизнес-процессов). Для начала достаточно нарисовать на листах А4 блок-схемы с краткими пояснениями. Кстати, эти схемы также можно дополнить примером проекта (если компания работает по проектам), да и вообще кратким описанием компании: род деятельности компании, актуальные направления, численность. В таком случае вы будете во всеоружии, общаясь с поставщиком: «Вот наши процессы, вот информация о нас – расскажите, подходят ли ваши решения, а лучше покажите на одном из представленных нами процессов в виде демо-версии или пилотного проекта».
Кроме того, надо подумать – есть ли у вас дополнительные требования к поставщику. Например, требуется обучение работе в ПО или полноценное внедрение выбираемого программного продукта. Это тоже важный момент: не все поставщики ПО вообще предоставляют подобные услуги.
2. Бюджет IT-проекта
Поставщикам ПО бюджет можно и не сообщать, но понимать, сколько ваш бизнес готов потратить – нужно. Если вовсе нет никакого понимания, всегда можно запросить пять-шесть коммерческих предложений под ваши требования (они же у вас теперь есть, верно?), и вывести среднее значение, которое вам подходит.
Зачем нужно понимать бюджет? Чтобы не распылять внимание. Можно потратить массу времени на ознакомление с ПО и потом неожиданно понять, что купить вы можете далеко не все из того, что смотрели – а время уже потрачено. Вы же не идете в салон Jaguar, если хватает только на Nissan?
Бесплатных и «копеечных» вариантов корпоративного ПО сейчас хватает, но дьявол кроется в деталях. Например, любой бесплатный вариант всегда будет лишь условно бесплатным. Если вы выделяете человека из собственного штата и ставите ему задачу внедрить бесплатное ПО своими силами, то его ФОТ (и сопутствующие расходы) – это уже бюджет. Если этот человек увольняется – сможет ли кто-то другой продолжить его работу? Это риск. Если вы арендуете ПО, данные из которого нельзя выгрузить в понятном формате при переходе на другое ПО – это еще одна статья расходов и снова риск. Если ПО стоит «три копейки», будьте также готовы к унификации. Если разработчик демпингует, захватывает рынок низкой стоимостью, то реагировать на ваши индивидуальные пожелания и запросы он вряд ли будет, так как вы для него – один из миллиона.
3. Ответственный за внедрение IT-решения
Правило работает не только для этой темы: если ответственных больше одного – их нет. Ответственный должен быть всегда один. И он должен уметь отстаивать свою точку зрения, а не всегда идти на поводу у руководства (а в идеале – принимать большинство решений самостоятельно).
Сложно понять кто ответственный? В небольших компаниях это часто кто-то из собственников. В компаниях покрупнее – кто-то из руководителей направлений или отделов. Главное, чтобы это был бизнес-пользователь, который будет принимать непосредственное участие в использовании системы (здесь вспоминаем, что у каждого процесса должен быть свой владелец – не исключено, что ответственным должен быть кто-то из владельцев ключевых процессов). Зачастую в качестве ответственного ставится IT-специалист, в задачи которого входит настройка компьютеров, локальной сети и поддержка серверов. И в 90% случаев выбор ИТ-специалиста в качестве ответственного – ошибка. Задачи IT-специалиста обычно поддерживающие, и не имеют отношения к развитию компании. А внедрение чего-то нового – это именно развитие, требующее другого образа мышления.
4. Сроки реализации IT-проекта
Задача без окончания всегда будет стремиться к бесконечности. Бессмысленно задавать конкретную дату окончания внедрения, но на момент начала выбора IT-продукта должна быть зафиксирована как минимум предполагаемая дата начала пилотного проекта и предполагаемый (желаемый) год завершения внедрения. Будьте реалистами: внедрение любой системы может длиться несколько месяцев или лет. Даже в том случае, если вы хорошо подготовились.
Что такое пилотный проект? Это не демо-версия, а по сути запуск полноценной работы, только для ограниченного круга лиц. Этот круг лиц (рабочая группа) должен объединять какой-то процесс или проект. Уточняйте у поставщиков, есть ли вообще возможность пилота (не исключено, что он будет платным – это нормально) и если есть – вот ваш ближайший горизонт планирования. По итогам пилота можно понять принципы внедрения, оценить сложности и спрогнозировать предполагаемые даты внедрения (по процессам или по отделам – в зависимости от компании).
Цикл продажи корпоративного ПО может длиться 6-18 месяцев, и все b2b-продавцы это знают. Если не можете определиться, когда хотите начать внедрение, то будьте готовы, что продавцы будут общаться с вами менее охотно, так как в принципе не понимают – собираетесь ли вы что-то покупать или нет. Кстати, задавать любые сроки должен тот, кто спонсирует это мероприятие (выделяет бюджет).
5. Стадия выбора ПО
Вы всегда должны понимать, на какой стадии приобретения ПО находитесь. Это задача ответственного: спланировать стадии (сбор информации, формирование требований, утверждение рабочей группы, презентации поставщиков и т.д.), определить ответственных за каждую стадию и утвердить стадии с руководством и рабочей группой. В дальнейшем – поддерживать стадии в актуальном состоянии.
Напоследок отмечу вот что. С завидной регулярностью в сети попадаются материалы, где авторы рассматривают десятки систем какого-либо класса (или даже смешивая сразу несколько разных классов) с точки зрения возможностей. Это серьезный труд – без шуток. Но рассмотреть 50 систем управления задачами и выяснить, что идеальной не существует – так себе подвиг. И сотни бессмысленно потраченных человекочасов на эти поиски вряд ли можно назвать полезными для бизнеса (да и общества). Идеального ПО действительно не существует. Однако, можно найти IT-решение, подходящее именно вам – причем относительно быстро и безболезненно, если построить фундамент из тех простых пунктов, которые мы только что рассмотрели. И тогда все будет на порядок проще.
Проблемы успешного введения корпоративного ПО в компанию можно выделить две главные, совершенно не отмеченные в статье.
Первая – низкое знание проблемной области сотрудниками ИТ компании. К сожалению, большинство их совершенно (или практически совершенно) не разбираются в работе компаний заказчиков, будь то промышленное производство или иное. Отсюда и пожелания напишите, нарисуйте нам блок-схему, а еще лучше опишите ваши процессы. Такой подход напрягает потенциального заказчика. Он чувствует недостаточный профессиональный уровень агента и с опаской начинает относиться и к его предложениям. И даже в том случае, когда он берется за это, то делает кучу ошибок ( уже в силу своего не понимания требований ПО), которые впоследствии только запутывают ситуацию. Низкое знание проблемной области затягивает сроки адаптации ПО и приводит к многим ошибкам со стороны исполнителя. Правильным была бы картина в которой приходят специалисты IT, проходятся по компании, разговаривают с сотрудниками, а потом на встрече с руководством дают краткую характеристику: что есть на сегодня, недостатки и прочие, и что они могут предложить с точки зрения изменения системы управления и внутрифирменных процессов.
Второе – большинство программных решений, поставляются в закрытых кодах. Это обусловлено логикой ИТ-компании, которая норовит продать дешево и потом отыграется на доработках и сопровождении. Рекомендуемое ПО совершенно не ориентируется на уровень подготовки специалистов компании заказчика. А идеальное ПО должно впоследствии обеспечить возможность своей доработки и развития самими сотрудниками компании (не специалистами ИТ подразделения, а сотрудниками на рабочих местах). Это весьма привлекательно для заказчика и обеспечит бурный рост развития системы. Для этого система должна поставляется в открытых кодах (или по крайней мере периферийная ее часть), иметь возможность прозрачной доработки на общественных языках, или иметь гибкий, с широким функционалом интерфейс.
Все остальное изложенное в статье будет потом, когда клиент подпишет контракт.
А я бы добавила «третье» и «четвертое» «главные», но отнюдь не последние пункты:
- умение управлять. Уж простите, говоря об инструменте, коим является любое ПО, надо понимать, для чего и как тот или иной инструмент будет использоваться. Тогда все остальные вопросы могут остаться за скобками, т.к. сейчас существует великое множество бесплатных или условно бесплатных продуктов, а также простая возможность создать что-то самим с нуля. Понятно, что такой выбор также имеет свои минусы, но умение управлять позволит принять верное решение.
- при этом управлять надо не ИТ, а всем комплексом работ, где ИТ – только часть.
Эти два пункта, безусловно, пересекаются с предыдущими пунктами «о главном» от Леонида Харитонова: дополнительным пунктом о знании ИТ-шниками предметной области и упоминанием открытых кодов.
Добавлю еще, что сегодняшние тенденции – комплексные знания и комплексная команда, отдельно стоящее ИТ уже устарело за редким исключением, с чем я полностью согласна.
Сама статья представляет собой классические выжимки из западных тренингов по выбору ПО, что тоже уже несколько устарело. Но польза для новичков в этой области, безусловно, есть.
Да, статья рассчитана именно на новичков - для тех, у кого это первый опыт. Тот факт, что мой опыт совпадает с выжимками - возможно, не вижу в этом проблемы, может в чём-то это даже к лучшему :) К сожалению, формат материалов не позволяет указать на кого в первую очередь нацелен материал (в плане опыта).
По вашим пунктам - конечно согласен. Возможно, попробую раскрыть эту тему в следующем материале.
Да, часто оно невысокое. И чтобы обезопасить себя - заказчику стоит задуматься о тех пунктах, о которых я пишу. Заказчики часто говорят "Ой, ну у нас как у всех - вы же с другими компаниями общаетесь!". Но в большинстве случаев выясняется - даже если отрасль одна, даже если уровень развития примерно совпадает, многое совсем не как у всех и чужой опыт (особенно в нашей действительности) может быть даже вреден.
По последнему вашему абзацу - согласен, но это в идеале. Потому что требует погружения и - соответственно - расходов. Хорошо работает, когда заказчик крупный (стоимость будущих проектов покрывает риски). Плохо - когда небольшой (денег нет, в компании хаос и разовый разговор совершенно не даст понимания что и как, только запутает).
Не совсем (ну, ладно - не всегда) такой логикой. Кроме того, открытый исходный код - актуальная тема, когда у заказчика в принципе есть ИТ-отдел. Это актуально для крупных компаний. Все остальные усиленно движутся в сторону SaaS, допиливать что-то под себя особо некому (часто вижу, что даже с настройками в корпоративном ПО многим разобраться некогда или желания нет - куда уж там о собственных доработках). Впрочем, в России в сторону SaaS в среднем смотрят ещё настороженно даже небольшие компании, но время показывает, что постепенно это недоверие сходит на нет.
У нас в компаниях работают в основном люди с высшим образованием, которые со школьной скамьи и далее в ВУЗах изучали основы информатики и программирования. И автор считает, что зря государство тратило на это деньги и этот потенциал не стоит использовать в производстве. Крайне ошибочное мнение. ИТ аутсорсинг -это еще одна попытка посадит Клиента на иглу зависимости и превратить в дойную корову. Облачные технологии будут развивается интенсивно. Приведу прекрасный пример, когда заказчику сдали систему реализованную на ACCESSе, с открытой информацией по структуре таблиц и программным модулям. Работники всех ведущих отделов (торговый, кадры, производство и пр.) самостоятельно разработали свои запросы и отчеты, тем самым ускорив решение производственных задач, которые зачастую меняются очень быстро. А привлекать программиста, втолковывать ему, что надо и ждать неделю – это для бизнеса очень дорого. Мы понимаем, что подобные реализации требуют иного корпоративного мышления, но за этим будет будущее. Эксплуатационные, эргономические возможности ИТ решений будут столь высокие, что потребность в посредничестве будет стерта.
Не знаю, может из статьи не прослеживается, что речь идёт не о заказных разработках? Я о коробочных продуктах, а их едва ли можно назвать ИТ-аутсорсингом.
Когда-то и машины летать будут, а человечество колонизирует Марс :)