Хабрахабр

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

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

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

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

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

Запись действий пользователей с временнЫми параметрами

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

Принцип простой:

  • записывает, когда пользователь открыл форму (документа, справочника, отчет, обработку);
  • записывает, когда он ее закрыл;
  • записывает, когда он ее записал (если это сохраняемый объект, вроде документа или справочника);
  • записывает, был ли это новый объект, или старый;
  • записывает все, что надо знать об объекте — ссылку, имя типа, имя пользователя, имя формы.

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

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

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

Разумеется, быстро объясняю, что никто им таких распоряжений не давал. Через день прибегает менеджер по отгрузке, говорит — кладовщики отказываются грузить машину, говорят, что им надо вбивать данные в какую-то систему и у них на это уходит 2 часа в день. Сказал менеджеру, сказал кладовщикам — все, больше таких заявлений от них не было. Открываю свой отчет, вижу — тратят в день 20 минут на всех.

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

Бухгалтерия говорит — нам надо расширить штат, у нас вырос документооборот. Третий пример. Руководство, памятуя о моем отчете, спрашивают — дай статистику, что там у них выросло и где.

Первый же подсчет в лоб — количество документов и количество строк в них — показал, что документооборот не вырос.

Ладно, думаю, может там что-то усложнилось в документах, реально может труднее стало их оформлять.

Смотрю «средний чек» и его динамику по двум бухгалтерам — нет, вроде не растет, не падает.

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

Заодно — немножно автоматизировать. Все, расширение штата отменилось, надо просто подождать, пока набьют руку.

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

Запись значений показателей

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

они воспроизводимы. Многие цифры запоминать не нужно, т.к. Например, нет нужды запоминать объем продаж — его всегда можно посмотреть ретроспективно.

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

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

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

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

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

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

И вуаля — «хороший» менеджер (аккуратная девочка) заказывал 85-100 % того, что требовала система, «плохие» — 15 %. Ставлю запись двух показателей индивидуально по каждому снабженцу — сколько каких позиций было к заказу на утро, сколько из них заказал в течение дня. Что интересно — снабженцы, увидев этот отчет, попросили дать его им в использование (сами снабженцы, а не их руководитель). Все, пошла работа с дисциплиной. Их отчет показывал текущие остатки, а мой еще показывал «время жизни» этих остатков. Разница между моим и их отчетом была простой. Все тот же Айсберг.

Фиксация идей

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

Я несколько лет назад заметил, что я их не запоминаю. У меня идей обычно много возникает, про качество судить не буду, но по факту их много. Бывает, что придумываю идею по несколько раз.

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

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

Мои — почти невозможно, т.к. Суть в том, что идеи стали публичными и зафиксированными, и украсть их стало сложно. на момент открытия системы для пользователей там уже содержалось несколько сотен моих записей.

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

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

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

Данные предоставили, процесс сдвинулся с мертвой точки.

Фиксация данных

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

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

Проблема еще в том, что момент «слетания оборотки» должен отслеживать человек.

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

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

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

Люди стали жаловаться на скачки остатков на складе («утром смотрю — 10 шт, в обед смотрю — 5 шт, а я уже клиенту пообещал, а я не дурак, вижу что движений не было неделю»). Первый пример использования. Смотрим в механизм — вуаля, остатки сегодня меняются, потому что изменились обороты за предыдущий месяц. Бухгалтерия говорит — мы ни при чем, все документы оформляются в течение суток, никаких исправлений задним числом. Спрашиваем — ты чего? Ковыряем — бухгалтер ввел новый документ месячной давности. Не успеваю, говорит.

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

Вопросы для контроля

Функционал контроля задач, проектов и т.д. есть, например, в 1С: Документообороте, наверняка многие видели. Там вы можете любой (или почти любой) объект поставить на контроль, установить дату, и у вас выскочит напоминание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Незабывайка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»