С основателем консалтинговой компании «Корада» Алексеем Бояршиновым мы побеседовали на волнующую тему сопровождения и поддержки корпоративных ИТ, и пока избавлялись от «костылей» и «конкретили» бизнес, кажется, обнаружили пару лайфхаков.
– Алексей, откуда вы узнали о Сообществе Инфостарт?
Сложно не знать о вас, занимаясь 1С. Мы регулярно посещаем Infostart Event, сам был два раза, отправляю своих ребят. Подписан на вашу группу в Facebook, слежу за публикациями и форумом на портале infostart.ru. А про журнал Infostart Journal и о вашей рубрике «Интервью» услышал недавно, кстати, от одного из ваших спикеров, Андрея Александровича, он тоже выступал на IE.
– В прошлом году на конференцию Инфостарт вы приехали с докладом о том, что нужно не просто внедрять ИТ, а превращать это в проекты организационных изменений.
У нашей компании есть такой подход: проводить автоматизацию предприятия, прежде всего, как проект его организационных изменений. На мой взгляд, это важная дискуссионная тема, потому что многие проблемы внедрений 1С, негативное восприятие 1С-ников в целом становятся понятны именно с такой точки зрения. Соответственно, это заставляет по-другому управлять проектом, иначе относиться к заказчику и целям внедрения. Хотелось бы рассказать об этом опыте более широкой аудитории.
– А в чем негатив по отношению к специалистам 1С со стороны бизнеса?
Ни для кого не секрет, что вход на рынок автоматизации с 1С довольно прост: освоить навыки установки «из коробки» – элементарно. Предложений – огромное количество. Первая проблема здесь – у заказчика, который наработался с фрилансерами. У него складывается ощущение, что 1С-ник – это такой мальчик, который сейчас придет и за еду что-нибудь поделает. «Оно все равно потом работать не будет, ну, да ничего страшного, мы его еще раз позовем, и еще раз, и еще…». И это – ловушка для клиента. Вроде бы, он и понимает, что процесс затягивается, и со всех сторон слышится: решение типовое, должно все работать с полпинка. А у него в итоге система уже испорчена, перекастомизирована, и клиент продолжает жить с этой вечной проблемой, пока что-то глобальное не произойдет: кризис, продажа бизнеса и тому подобное.
Другой пример – по каким-то своим причинам фрилансер отказывается дальше работать с заказчиком, и выясняется, что никто не готов принять систему на сопровождение. Потому что она не обновлялась давно, 50 релизов пропущено, надо ставить опять с нуля. А заказчик в принципе не обязан разбираться в рынке 1С-поставщиков, что там есть компании, которые хорошо свою работу делают, а есть, кто похуже, а бывают и частные лица – тоже очень разные. И что может повезти, и найдется грамотный ответственный специалист, а может, и наоборот. Но для среднего заказчика от бизнеса они все – некий монолит, единообразный рынок услуг.
– Но фрилансеры – это один уровень требований, а франчайзи – уже совсем другой, или как?
Ну, вообще по-разному бывает. Хотя, безусловно, у франча как у компании, как правило, есть хоть какой-то методический подход, соблюдаются какие-то предписания и стандарты 1С. Он понимает, что клиента надо сопровождать, систему – обновлять по условиям договора. Фирма «1С» заставляет их поддерживать какой-то порядок.
– То есть весь бардак с автоматизацией управления и учета – от «внесистемных» фрилансеров?
Это одна половина проблемы, заметная, скорее, в малом масштабе простых задач. Вторая половина – когда мы говорим про более или менее значимый для заказчика проект, например, внедрения УТ, Розницы или УНФ. Если говорить об аутсорсе, такими вещами частные специалисты не занимаются, и все ошибки внедрения совершают уже ИТ-компании. Самая типичная из них – отношение к внедрению системы буквально как к внедрению системы. Условно, аутсорсер работает так: продаем лицензии, заполняем с клиентом опросный лист, ставим систему, настраиваем – распишитесь-получите. Ну, пользователей обучим еще, так и быть. А почему-то в итоге работает совсем не так.
– В чем причина такого результата?
На мой взгляд, успех проекта внедрения зависит от того, насколько для этого были необходимы изменения в самой компании заказчика и удалось ли их провести. Поэтому мы за восемь лет пришли к тому, что называем ЕППА – «единственно правильным подходом к автоматизации». К тому, что внедрение системы – любой, в том числе, 1С – это организационные изменения. Как минимум, меняем принятые у пользователей заказчика подходы к работе. Часто бизнес-процессы тоже меняем, потому что схемы, заложенные в решениях 1С – это своего рода лучшие практики, но в реальности у заказчиков встречаются очень странные и далеко не оптимальные алгоритмы.
Мы также меняем пользовательские интерфейсы – в первую очередь, то, как пользователи должны работать в системе. Но главное, мы меняем подход к управлению компанией заказчика в целом. Ведь цель внедрения, в конечном итоге, чтобы руководство владело актуальной информацией и могло своим бизнесом адекватно управлять. Если про это забыть, то получится, что в ходе внедрения мы просто взяли систему, поставили, а про изменения, которые нужно произвести, чтобы она подошла, не подумали. Так и случается, что она в итоге не подходит.
– Хорошо, допустим, вы с клиентом идете правильным путем. Что должен поменять топ-менеджмент заказчика в своих привычках?
Я поясню на недавнем примере. Собственник компании, по совместительству гендиректор, принципиально не работал в корпоративных системах как пользователь вообще. У него был специальный человек, которого он звал «информационный костыль». Этот человек по запросу вроде «нужно по брендам проанализировать продажи» шел сначала к аналитику коммерческого отдела, потом к программисту, собирал какие-то цифры, набивал вручную в таблицу Excel, раскрашивал красивыми цветами и потом нес учредителю. На всю эту историю уходило два-три дня.
В данном случае, необходимое ключевое изменение для руководства – научиться работать со своей учетной системой. Потому что вся польза от нее, если она вообще есть, заключена в том, что ты как руководитель получаешь возможность принимать решения оперативно. Скажем, нужно решить, будем мы работать с неким поставщиком дальше или нет – все данные для этого есть в системе, но нужно уметь ей пользоваться. И если руководитель высшего звена пользуется, хотя бы отчетами, то он уже начинает понимать – ага, вот я этот отчет сейчас строю, он был бы полезен, но у меня нет цифр, а почему? А потому что кто-то не внес в систему свои данные. И тут глава компании превращается в драйвера всего проекта внедрения. Он осознает реальную пользу от решения, не потому, что так сказал его ИТ-директор, а на собственном опыте – для него система становится источником управленческой информации.
Если же руководство не меняет подход к управлению, для него все это внедрение ехало-болело, ноль реакции. Будут продолжать хромать на «информационных костылях». А чего внедряли, зачем оно надо – не понятно. И пытаться объяснить таким людям, что вот, смотрите, у вас сотрудники не хотят вносить данные, саботируют внедрение – это бесполезно, они сами не видят реального смысла в проекте.
– Но если даже смысл есть, хорошо бы в чем-то его измерить. Автоматизация предполагает какую-то методику оценки ключевых показателей эффективности?
Каждый проект требует индивидуального подхода, куча показателей влияет на все. Кроме того, что система чисто функционально работает корректно, и сотрудники ей пользуются, важным показателем успешности является уровень стресса, который компания пережила. Чем меньше усилий заказчик потратил на адаптацию к новым условиям работы, тем лучше.
Разумеется, его в любом случае будет трясти, особенно на крупных проектах. Но когда мы подходим к внедрению с точки зрения организационных изменений, мы с самого начала собираем некую инициативную группу пользователей – они впоследствии станут проводниками и миссионерами новой системы в своей организации. Мы привлекаем их к принятию решений, обсуждаем с ними, как те или иные процессы будут меняться и как мы их автоматизируем. Предлагаем им различные сценарии и варианты развития событий, и получается, что уже с первых этапов сами пользователи, которые со стороны заказчика – они соавторы этого проекта. Как следствие, сопротивление нововведениям ниже, и внедрение менее болезненно. Все типичные вопросы – зачем, почему именно такая система, что мы теперь будем делать, как жить – таким образом можно успешно закрыть сразу, а не откладывать на стадию обучения после внедрения.
– Кого приглашаете в инициативную группу?
Важно, чтобы эти пользователи были в том или ином смысле неформальными лидерами в коллективе заказчика. Они же потом будут нести коллегам свое видение и впечатления от системы. Это могут быть не только руководители подразделений, но и старейшие опытные работники компании, которые знают о ней все.
Нужно отметить, что участие в инициативной группе не означает руководство проектом – управляем внедрением мы, но эти люди чувствуют свою сопричастность происходящему процессу и результатам изменений. Наша задача – дать им это ощущение, тогда оно станет очень сильным мотиватором. Само по себе ощущение того, что ты участвуешь в общем успехе. Это, собственно, один из ключевых наших тезисов – вовлекать людей заказчика в проект с самого начала.
– Если на каком-то этапе увидите, что для решения трудной задачи не хватает ресурсов со стороны сотрудников – рабочего времени, рук, компетенций, – что для вас окажется в приоритете: люди или задача? С какой чаши весов начнете?
В проекте внедрения, конечно, все определяет задача. Если ее никак нельзя модифицировать в рамках плана и проектной методологии, нельзя отменить, то будем решать кадровый вопрос, чтобы задачу выполнить. Вообще, в самом начале проекта проводятся стартап-встречи. Первая – наша внутренняя, мы обсуждаем, какая будет команда, распределяем роли, изучаем проектные риски, готовим эскиз устава проекта.
А затем встречаемся с клиентом. Практика последнего времени показывает, что эта вторая встреча нереально важна. У нее есть свой формат – своего рода мотивационный спич, где мы собираемся с командой заказчика и рассказываем, ради чего мы здесь, как все будет происходить. Тут же на месте оперативно корректируем какие-то цели и задачи по желанию заказчика. Говорим о том, как важно работать вместе в одной команде. Очерчиваем некий вектор будущего движения к успеху.
Если по каким-то причинам такую встречу провести не удается, проект получается смазанным. Вроде как, по ходу внедрения проводим регулярные встречи, но у них у всех не было отправной точки. Бывает, что руководитель проекта со стороны заказчика говорит – не хочу никакой стартап-встречи, я боюсь выступать перед людьми. И что, мы должны из-за него подставить всю команду и проект завалить? Лучшим решением здесь будет предложить ему помощь, ассистента, снять с него лишнюю стрессовую нагрузку в моменте, и затем постепенно обучить его этому навыку.
– Здорово, но, кроме методологических, ведь есть еще и задача управлять изменениями требований заказчика. Когда проект уже идет полным ходом, а от вас внезапно требуют то, чего вы ну никак не впишите в адекватные бюджеты и сроки. А может, элементарно не понимаете.
Тут надо «конкретить» заказчика, добиваться четкости и согласованности. Чтобы ситуации, когда требования вдруг меняются на прямо противоположные или вообще невероятные, свести к минимуму. Уже на стадии коммерческого предложения следует стремиться, по возможности, к однозначным и ясным формулировкам требований и результатов – прописать границы проекта, что делаем, а что – нет. Например, если у заказчика несколько объектов автоматизации, нужно указать конкретный перечень адресов, где будет проходить внедрение. Определить организационные границы – точный список всех юрлиц клиента.
Это позволит вести предметный разговор, когда заказчик начнет менять первоначальные требования. И вы как исполнитель либо получите больше ресурсов и возможностей для своей команды под новые задачи, либо заказчику придется отказаться от какой-то части своих запросов, может, отложить до лучших времен. В любом случае, важен взаимовыгодный компромисс.
– Вы как-то отслеживаете, что происходит у заказчика после внедрения? Если не говорить о стандартной техподдержке.
Когда клиент из крупного бизнеса, у него, как правило, есть своя ИТ-служба, которая берет на себя сопровождение всех корпоративных систем. Но это не значит, что для нас история закончилась. Мы проводим оценку результатов, условно говоря, через пару месяцев после акта приемки связываемся с заказчиком и получаем обратную связь о том, решены ли задачи и в какой степени.
Если выясняем, что есть какие-то несоответствия и недочеты в нашей работе, мы коллективно обсуждаем внутри себя, переоцениваем риски, пересматриваем шаблоны устава проекта, опросные листы для первичного обследования клиента. И суммируем опыт в наших регламентах.
– Поделитесь им на следующей Infostart Event?
И не только – надеюсь, обменяемся опытом с другими компаниями, которые занимаются внедрением и сопровождением решений 1С. Сейчас такого обмена не хватает.
Уважаемые читатели! Приглашаем вас стать спикерами нашей рубрики и дать интервью, в котором вы сможете поделиться своим профессиональным опытом, историями успеха ваших компаний и высказаться по широкому кругу вопросов из сферы ИТ и 1С-разработки. Просто обратитесь в редакцию Инфостарт: dkochergov@infostart.ru, +7(812)309-06-46, доб. 138.