Экзорцизм программистскими методами 2

За полтора года, прошедших с момента публикации первого экзорцизма, вспомнились еще некоторые методы, и появились новые.

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

Моя статья — про зло помельче. Про саботаж внедрений, про вечное «я все правильно делаю, это ваша программа виновата», про раздутие штата, про мелкие корпоративные интрижки и сопротивление переменам.

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

Просто опыт применения некоторых инструментов и примеры того, как они меня выручали.

Учет затрат на автоматизацию

Технически это очень просто. Есть учет задач и проектов в системе. В каждой задаче есть некая оценка трудозатрат — либо часы, либо баллы по покеру планирования. Зарплату программистов мы знаем. Заказчик, его подразделение и руководитель известны.

Берем зарплату программиста и распределяем на решенные за месяц задачи. Получается стоимость решения конкретной задачи. Можно собрать по проекту, по заказчику, по подразделению.

Первый пример использования — защита от наездов типа «нами не занимаются, наши задачи не решают». Открываем отчет, смотрим — ага, на автоматизацию бухгалтерии компания потратила 250 т.р. за прошлый месяц. Или 1.5 млн. рублей в год, например.

Тут фишка в том, что оценивается в рублях — единице измерения, понятной директору. Если сказать «мы решили 113 задач от бухгалтерии», то он не проникнется — скажет, что надо еще больше делать. А когда говоришь «ты потратил 1.5 млн. на их задачи», ему будет неловко сказать «потратьте еще 2 млн. моих денег на них!». Чаще всего он вздыхал и спрашивал у бухгалтерии, что за задачи такие, на которые надо 1.5 млн. рублей тратить.

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

Мы решили вывернуть поинтереснее. В решенных задачах стали указывать не только заказчика, но и имена метаданных — документов, справочников и т.д., которые были созданы или доработаны при решении этой задачи.

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

А у нас затраты посчитаны. Допустим, это 30 т.р. Метаданные мы знаем, количество объектов знаем, делим одно на другое — получается, что в нашей системе на учет одного средства измерения потрачено 30 т.р. Хотя само средство измерения стоит 1 т.р.

Когда начальник службы качества в следующий раз на совещании начинает рассказывать, что ему надо чего-то автоматизировать, вежливо спрашиваем — как поживает «золотой штангенциркуль», на учет одной поверки которого компания потратила 30 т.р.?
 

Учет затрат на тех.поддержку

У нас на тех.поддержке сидел один человек — дежурный. Я от него часто слышал что-нибудь вроде «как же она достала, дура тупая, каждый день одно и то же спрашивает». Сначала не обращал особого внимания — мало ли, человек не запомнил, или мы виноваты. Потом, окольными путями, узнал, что некоторые пользователи сознательно устраивают DDoS-атаки на тех.поддержку, потому что не любят ИТ-отдел.

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

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

Ну а дальше просто. Общая стоимость тех.поддержки нам известна из предыдущего пункта. Делим деньги на время обращений, получаем цифру — какой человек и отдел сколько денег компании тратит на себя.

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

Второй пример использования — поинтереснее. Мы его называли «стоимость некомпетентности». К сожалению, наши HR не очень разбирались в тонкостях учета, и требование в вакансиях «Знание программ 1С» проверять не умели, а к нам отправлять на тесты не хотели. Так к нам попадали бухгалтеры, не знающие, как вести учет в компьютере.

И вот есть бухгалтер, которому платят 30 т.р. в месяц, без учета налогов. И есть стоимость тех.поддержки, оказываемой этому бухгалтеру. Например, 20 т.р. в месяц — программисты же дорогие. Получается, бухгалтер обходится компании в 50 т.р. в месяц. Столько же стоит, например, заместитель главного бухгалтера.

Директор был немного ошарашен этими цифрами. Одно дело слышать «мы тратим 50 т.р. в месяц на тех.поддержку пользователей» — ну ладно, надо так надо. Совсем другое дело — «некомпетентность этого бухгалтера стоит нам 20 т.р. в месяц». Обращений на тех.поддержку стало меньше.
 

Незабывайка

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

Нас такой подход не устраивал, потому что все снова приходило к ситуации «программисты плохие». Поэтому мы поступили просто — начали использовать накопленную статистику затрат на автоматизацию.

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

Когда снова заходит разговор о том, что мы не решаем каких-то задач, или кто-то плохо автоматизирован, мы просто поднимали отчет, и показывали накопленную сумму. Т.к. у нас была статистика в разрезе метаданных, то сумма хорошо делилась на две части — хорошую и плохую.

Хорошая — используемый функционал. Плохая — неиспользуемый. У кого-то плохая была вдвое больше хорошей.
 

Парсинг версий

Системы версионирования, что в 1С, что в том же CouchDB, работают одинаково — просто хранят версии объектов на момент записи. Некоторые доделывают эти системы — например, не сохраняют версии, если ничего в объекте не поменялось.

Наши пользователи, прошарив, что мы анализируем их работу, в том числе, с помощью версионирования, стали просто почаще перезаписывать документы. Ну так, на всякий случай.

Мы расстроились, т.к. могли потерять один из инструментов влияния и защиты своих интересов. Но программистский ум подсказал решение — пусть себе перезаписывают, сколько хотят, мы будем парсить и анализировать версии на предмет осмысленности изменений.

Бухгалтеры, например, люди ушлые, но портить учет опасаются — если перезаписывают объект, то меняют какой-нибудь незначительный реквизит, вроде комментария. Формально, версия — новая, даже если фильтровать по наличию изменений.

Мы добавили такую сущность, как view осмысленности. Просто перечислили свойства объектов, изменение которых, скорее всего, является нормальным отражением работы человека, а не ИБД. Вьюшек было несколько, на один и тот же тип объекта. Например, изменение номенклатуры в отгрузке — это серьезное изменение. Изменение счета учета — так себе, не очень серьезное, но все-таки — работа. Изменение времени документа внутри одной даты — нет, увы, просто детское баловство.

Так у нас появилась статистика изменений в разрезе осмысленности. Пользователи, естественно, прошарили и стали опять DDoS’ить — меняют важный реквизит, через минуту, или день меняют обратно. Наивные.

У нас ведь есть возможность сравнивать версии не последовательно, а, например, первую и последнюю, и игнорировать промежуточные изменения. Когда квартал закрыт, документ, с высокой вероятностью, уже в целевом состоянии, и можно смело сравнивать его с последней версией на дату создания.
 

Корреляция автоматизации и KPI

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

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

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

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

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

Имея KPI и затраты на автоматизацию, очень просто посчитать корреляцию, потому что все данные хранятся с привязкой к датам. Выполнили, например, проект автоматизации стоимостью 200 т.р. в январе — должны измениться KPI соответствующего подразделения. Не сразу, а, допустим, в феврале, или в марте, или даже в июне. Но должны. Иначе в чем смысл?

Как ни странно, корреляция была. Например, в работе закупок — мы сделали проект автоматизации по ТОС, и их KPI выросли. Даже продажи выросли, т.к. именно они были целью автоматизации закупок, в конечном итоге.

Но были и примеры отсутствия корреляции. Например, внедрение CRM не принесло ничего, вообще. Создание сайта, взамен предыдущего, не принесло никакого эффекта.

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

А вот автоматизация экономистов, ведущих бухгалтерский учет, сказалась позитивно — мы лишились двух сотрудников. Их не увольняли — они сами ушли, по своим причинам. Но мы предложили — давайте пока не брать новых, посмотрим, как пойдет, мы там много автоматизировали. Директор согласился, и все получилось.

После посчитанной корреляции руководство стало иначе смотреть на автоматизацию. Ну и на программистов, разумеется. Особенно в свете того, что нам расчет этой корреляции никто не заказывал — это была наша инициатива.

Правда, потом директор сменился, и все пришлось начинать с самого начала. Но, где-то через полгода, новый директор тоже оценил расчет корреляции.