Есть много материалов о том, как внедрение информационных систем помогло компаниям избавиться от потерь, сократить затраты, вырубить на корню воровство. Это прекрасно, когда получается избавляться от зла в таком большом объеме.
Моя статья — про зло помельче. Про саботаж внедрений, про вечное «я все правильно делаю, это ваша программа виновата», про раздутие штата, про мелкие корпоративные интрижки и сопротивление переменам.
Все в статье — из личного опыта, с примерами использования. На уникальность и полное раскрытие темы не претендую, высшей истины здесь нет, обобщений старался избежать, ничего не навязываю.
Просто опыт применения некоторых инструментов и примеры того, как они меня выручали.
Честно не помню, зачем я эту штуку сделал, но пригодилась она несколько раз. Разработка простая и топорная, занимает не больше часа. Не везде применима, т.к. может отъедать много ресурсов и данные занимают значительное место на диске, поэтому за ней нужно следить.
Принцип простой:
В итоге имеем большую таблицу с данными, и несколько вычисляемых цифр. Например, знаем «средний чек» — сколько времени уходит на создание приходной накладной у бухгалтера. Знаем, сколько раз бухгалтер возвращается к ранее созданному документу, чтобы его изменить, и сколько тратит на это времени.
Приведу примеры, когда механизм пригодился.
Первый — устранение мелкого саботажа внедрения. Внедрялся механизм комплектации заказа на складе — кладовщик должен был отмечать собранные в ящик позиции. Кладовщикам было четко сказано — без фанатизма, работайте с системой только когда будет время свободное.
Через день прибегает менеджер по отгрузке, говорит — кладовщики отказываются грузить машину, говорят, что им надо вбивать данные в какую-то систему и у них на это уходит 2 часа в день. Разумеется, быстро объясняю, что никто им таких распоряжений не давал. Открываю свой отчет, вижу — тратят в день 20 минут на всех. Сказал менеджеру, сказал кладовщикам — все, больше таких заявлений от них не было.
Второй пример. Финдир заказывает некий функционал для управления деньгами. Что важно — не потому, что хочет, а потому, что этого контура учета не хватает вышестоящим. Потом на общем совещании его спрашивают — ну чего, когда данные появятся? Он говорит — там ошибки, не работает, мы программистам задание на доработку напишем. Открываю отчет, показываю — ни он, ни его девочки ни разу не заходили ни в документ, ни в отчет. Все, внедрение двинулось дальше.
Третий пример. Бухгалтерия говорит — нам надо расширить штат, у нас вырос документооборот. Руководство, памятуя о моем отчете, спрашивают — дай статистику, что там у них выросло и где.
Первый же подсчет в лоб — количество документов и количество строк в них — показал, что документооборот не вырос.
Ладно, думаю, может там что-то усложнилось в документах, реально может труднее стало их оформлять.
Смотрю «средний чек» и его динамику по двум бухгалтерам — нет, вроде не растет, не падает.
Тут дошло — недавно ушла в декрет давно работавшая девушка-бухгалтер, на его место взяли двух новых. Данные у меня были по всем трем, сравниваю — ба, вот оно. Два новых бухгалтера вводят документы медленнее, чем один старый.
Все, расширение штата отменилось, надо просто подождать, пока набьют руку. Заодно — немножно автоматизировать.
Из третьего примера следует четвертый, уже позитивный. Видя динамику «среднего чека» по типам объектов, мы стали ее использовать для анализа автоматизированности операций и последствий вносимых изменений. Если «средний чек» подрастал, то анализировали причины, наблюдали за людьми вживую и улучшали.
Технически это очень простое решение. Суть его проста — пишется запрос, который вычисляет какую-то цифру и сохраняет ее в системе с нужной периодичностью. В итоге имеем динамику по времени для цифры.
Многие цифры запоминать не нужно, т.к. они воспроизводимы. Например, нет нужды запоминать объем продаж — его всегда можно посмотреть ретроспективно.
Но некоторые цифры можно воспроизвести, только подняв бэкап базы. Например, только так можно узнать, сколько у вас было отрицательных остатков по товарам месяц назад. Кто читал предыдущие мои статьи, понимает, что речь об Айсберге.
Первый пример использования. Есть проблемы с зачетом аванса — достаточно большая сумма висит одновременно на 60.01 и 60.02. Функционал типовой, методических трудностей нет — просто укажи правильную аналитику в документах, и аванс зачтется. На совещаниях бухгалтерия говорит — нет проблем, сделаем. На каждом следующем совещании повторяет — делаем, там много работы, автоматизировано плохо. На меня смотрят косо.
Прихожу, включаю запись показателя — суммы незачтенного аванса. Думаю — нет, отмажутся, скажут что незачтенный аванс растет быстрее, чем они его исправляют. Делю показатель на три части — сумма на начало года, сумма на начало месяца, сумма на сегодня.
На следующем совещании показываю цифры — как было и как стало. Незачтенный аванс на начало года и начало месяца стоит колом — ничего не исправляли. Незачтенный аванс на сегодня почти не изменился — значит, сейчас документы нормально оформляют. В итоге старые ошибки исправили за 2 дня.
Второй пример использования. Автоматизировали снабженцев, функция простая — программа говорит, сколько чего надо заказать у поставщиков, бери и заказывай. Отдельно, указанный механизм пишет уровень текущий дефицитов. Смотрим — по одним позициям дефицит уменьшается, по другим растет. За позиции отвечают разные люди. На совещании все говорят — да-да, все делаем как велено, смотрим, заказываем. Почему дефициты растут — не знаем, наверное автоматизация плохая, цифры неверно посчитаны. Все косо смотрят на меня.
Иду в лоб — смотрю оформленные заказы поставщикам. Сходу разобраться не удается, т.к. документы вводятся и изменяются не оперативно — это нормально, т.к. процесс согласования заказа может занимать несколько дней, и он все это время корректируется.
Ставлю запись двух показателей индивидуально по каждому снабженцу — сколько каких позиций было к заказу на утро, сколько из них заказал в течение дня. И вуаля — «хороший» менеджер (аккуратная девочка) заказывал 85-100 % того, что требовала система, «плохие» — 15 %. Все, пошла работа с дисциплиной. Что интересно — снабженцы, увидев этот отчет, попросили дать его им в использование (сами снабженцы, а не их руководитель). Разница между моим и их отчетом была простой. Их отчет показывал текущие остатки, а мой еще показывал «время жизни» этих остатков. Все тот же Айсберг.
Несколько раз слышал от программистов, что у них воруют идеи, особенно начальники. Слушают идею, потом говорят, что она ни о чем, а через какое-то время выдают за свою.
У меня идей обычно много возникает, про качество судить не буду, но по факту их много. Я несколько лет назад заметил, что я их не запоминаю. Бывает, что придумываю идею по несколько раз.
Потом увидел на сайте студии Артемия Лебедева, что они записывают идеи, и считают это полезным. Решил поступить также — в системе учета задач сделал себе раздельчик, куда стал эти идеи записывать. Он был доступен только под полными правами, т.к. нужен был только мне.
Потом в компании решили систематизировать работу с рационализаторскими предложениями — подачу, оценку, учет реализации и т.д. Меня спросили, можно ли автоматизировать, я сказал — уже все автоматизировано, показал свой механизм. Немного доработал, чтобы было голосование, комментарии, учет реализации, постановка задач и т.д. Но суть не в этом.
Суть в том, что идеи стали публичными и зафиксированными, и украсть их стало сложно. Мои — почти невозможно, т.к. на момент открытия системы для пользователей там уже содержалось несколько сотен моих записей.
Первый пример использования даже не требовал моего участия. Идеи читали многие, и когда кто-то где-то высказывал предложение, читатели ему открыто говорили — а, была такая идея, посмотри в системе, там и обсуждение есть. Если я не присутствовал в этом разговоре, то выдумщика присылали ко мне, и обычно он начинал фразу с «ты вот идею такую предлагал, я почитал, она интересная, давай реализуем...».
Второй пример связан с продвижением системы рационализаторских предложений. К функционалу фиксации идей я, естественно, прицепил отслеживание прочтения. И получалось так, что сотрудники некоторых отделов, реально стремившиеся изменить свою работу к лучшему, начали вносить свои предложения в систему. Но реализовывались только предложения, связанные с автоматизацией, т.к. они адресовались мне, а мне это было интересно.
На совещаниях руководителям задавался вопрос — как у вас с реализацией предложений? Есть полезные идеи от ваших сотрудников? Многие дружно отвечали — не, ничего интересного, ерунда всякая. Показываю отчет — в систему вообще не заходили, ни одной идеи не прочитали, не говоря уж о реализации. На всякий случай переспросили у сотрудников — может вы устно или по почте свои предложения даете руководителям? Нет, говорят, отродясь такого не было, и вообще боимся голову поднять.
Данные предоставили, процесс сдвинулся с мертвой точки.
Цель этого механизма — расширить возможности версионирования. Обычно версионирование (как типовое, так и не типовое) фиксирует изменения первичных данных — справочников, документов и т.д. В реальной практике этого бывает недостаточно.
Например, «слетела оборотка» с разными вариациями «слетания». Традиционный путь — либо смотреть изменения документов, которые могли повлиять, либо поднимать бэкап, выгружать детализацию в эксель и сравнивать обороты.
Проблема еще в том, что момент «слетания оборотки» должен отслеживать человек.
В итоге сделал несложный механизм, который красиво хранит свернутую структуру оборотов и реагирует на изменения. И область данных, которую фиксировать, и свертка, и периодичность — настраивается через запрос.
Не вдаваясь в детали, механизм сигнализировал об изменениях области данных («слетела оборотка») в течение часа (это периодичность срабатывания регл.задания), указывал область данных, указывал период, и давал возможность найти первичные данные.
Да, и позволял «принять изменения» — если все было честно, то измененные данные становились эталонными, и слежка шла уже за изменениями.
Первый пример использования. Люди стали жаловаться на скачки остатков на складе («утром смотрю — 10 шт, в обед смотрю — 5 шт, а я уже клиенту пообещал, а я не дурак, вижу что движений не было неделю»). Бухгалтерия говорит — мы ни при чем, все документы оформляются в течение суток, никаких исправлений задним числом. Смотрим в механизм — вуаля, остатки сегодня меняются, потому что изменились обороты за предыдущий месяц. Ковыряем — бухгалтер ввел новый документ месячной давности. Спрашиваем — ты чего? Не успеваю, говорит.
Второй пример использования. Я фиксировал данные о продажах — просто потому, что на этой области данных тестировал механизм. Считалось, что данные о продажах меняются максимум неделю, и то в редких случаях, когда допущены ошибки. А тут смотрю — изменились продажи прошлого месяца. Сами понимаете, за прошлый месяц менеджер по продажам уже премию получил. Вижу, что бухгалтер изменил — ты чего, говорю? Оказалось, менеджер заставил, потому что сам перемудрил, клиента запутал. После этого случая бухгалтер так делать перестал.
Функционал контроля задач, проектов и т.д. есть, например, в 1С: Документообороте, наверняка многие видели. Там вы можете любой (или почти любой) объект поставить на контроль, установить дату, и у вас выскочит напоминание.
Мне типовой не понравился, т.к. он не позволяет делать контроль многоэтапным — например, сделать так, чтобы напоминание выскочило 10 раз с периодичностью в неделю. Поэтому я сделал свой простецкий механизм, основное отличие которого — он позволяет вести историю контроля, и растягивать его на какой угодно срок.
Например, я инициирую изменение в бизнес-процессах. Пишу соответствующие письма, провожу встречи и т.д. Записываю себе в систему этот вопрос, ставлю точку контроля — через неделю, пишу комментарий типа «переспросить Васю». Через неделю вижу напоминание, переспрашиваю Васю, Вася говорит «ааа, слушай, у нас завал, пока некогда». Ок, говорю, ставлю следующую точку — через неделю. Вижу напоминание, захожу — вижу историю. Переспрашиваю Васю, у Васи опять завал. Говорю — Вася, ты это уже говорил. Вася клянется, что это было в последний раз. Через неделю движение все-таки начинается.
Выглядит, как ерунда какая-то банальная, и вроде все это почтой можно разрулить, но, как сказано в начале статьи, на истину не претендую. Применение этого инструмента и подхода несколько раз меня выручало, когда банально нужно добиться чего-то от людей, которые тебе не подчиняются. Поставить задачу ты им не можешь, а идти через верх в данной конкретной ситуации не по-пацански — люди вообще ничего делать не будут.
Технически это очень просто. Есть учет задач и проектов в системе. В каждой задаче есть некая оценка трудозатрат — либо часы, либо баллы по покеру планирования. Зарплату программистов мы знаем. Заказчик, его подразделение и руководитель известны.
Берем зарплату программиста и распределяем на решенные за месяц задачи. Получается стоимость решения конкретной задачи. Можно собрать по проекту, по заказчику, по подразделению.
Первый пример использования — защита от наездов типа «нами не занимаются, наши задачи не решают». Открываем отчет, смотрим — ага, на автоматизацию бухгалтерии компания потратила 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 и затраты на автоматизацию, очень просто посчитать корреляцию, потому что все данные хранятся с привязкой к датам. Выполнили, например, проект автоматизации стоимостью 200 т.р. в январе — должны измениться KPI соответствующего подразделения. Не сразу, а, допустим, в феврале, или в марте, или даже в июне. Но должны. Иначе в чем смысл?
Как ни странно, корреляция была. Например, в работе закупок — мы сделали проект автоматизации по ТОС, и их KPI выросли. Даже продажи выросли, т.к. именно они были целью автоматизации закупок, в конечном итоге.
Но были и примеры отсутствия корреляции. Например, внедрение CRM не принесло ничего, вообще. Создание сайта, взамен предыдущего, не принесло никакого эффекта.
Вся автоматизация бухгалтерии приносила только отрицательный эффект, особенно на численность их штата, несмотря на все наши усилия по сдерживанию этой раковой опухоли компании.
А вот автоматизация экономистов, ведущих бухгалтерский учет, сказалась позитивно — мы лишились двух сотрудников. Их не увольняли — они сами ушли, по своим причинам. Но мы предложили — давайте пока не брать новых, посмотрим, как пойдет, мы там много автоматизировали. Директор согласился, и все получилось.
После посчитанной корреляции руководство стало иначе смотреть на автоматизацию. Ну и на программистов, разумеется. Особенно в свете того, что нам расчет этой корреляции никто не заказывал — это была наша инициатива.
Правда, потом директор сменился, и все пришлось начинать с самого начала. Но, где-то через полгода, новый директор тоже оценил расчет корреляции.
Моя статья — про зло помельче. Про саботаж внедрений, про вечное «я все правильно делаю, это ваша программа виновата», про раздутие штата, про мелкие корпоративные интрижки и сопротивление переменам.
Все в статье — из личного опыта, с примерами использования. На уникальность и полное раскрытие темы не претендую, высшей истины здесь нет, обобщений старался избежать, ничего не навязываю.
Просто опыт применения некоторых инструментов и примеры того, как они меня выручали.
Запись действий пользователей с временнЫми параметрами
Честно не помню, зачем я эту штуку сделал, но пригодилась она несколько раз. Разработка простая и топорная, занимает не больше часа. Не везде применима, т.к. может отъедать много ресурсов и данные занимают значительное место на диске, поэтому за ней нужно следить.
Принцип простой:
- записывает, когда пользователь открыл форму (документа, справочника, отчет, обработку);
- записывает, когда он ее закрыл;
- записывает, когда он ее записал (если это сохраняемый объект, вроде документа или справочника);
- записывает, был ли это новый объект, или старый;
- записывает все, что надо знать об объекте — ссылку, имя типа, имя пользователя, имя формы.
В итоге имеем большую таблицу с данными, и несколько вычисляемых цифр. Например, знаем «средний чек» — сколько времени уходит на создание приходной накладной у бухгалтера. Знаем, сколько раз бухгалтер возвращается к ранее созданному документу, чтобы его изменить, и сколько тратит на это времени.
Приведу примеры, когда механизм пригодился.
Первый — устранение мелкого саботажа внедрения. Внедрялся механизм комплектации заказа на складе — кладовщик должен был отмечать собранные в ящик позиции. Кладовщикам было четко сказано — без фанатизма, работайте с системой только когда будет время свободное.
Через день прибегает менеджер по отгрузке, говорит — кладовщики отказываются грузить машину, говорят, что им надо вбивать данные в какую-то систему и у них на это уходит 2 часа в день. Разумеется, быстро объясняю, что никто им таких распоряжений не давал. Открываю свой отчет, вижу — тратят в день 20 минут на всех. Сказал менеджеру, сказал кладовщикам — все, больше таких заявлений от них не было.
Второй пример. Финдир заказывает некий функционал для управления деньгами. Что важно — не потому, что хочет, а потому, что этого контура учета не хватает вышестоящим. Потом на общем совещании его спрашивают — ну чего, когда данные появятся? Он говорит — там ошибки, не работает, мы программистам задание на доработку напишем. Открываю отчет, показываю — ни он, ни его девочки ни разу не заходили ни в документ, ни в отчет. Все, внедрение двинулось дальше.
Третий пример. Бухгалтерия говорит — нам надо расширить штат, у нас вырос документооборот. Руководство, памятуя о моем отчете, спрашивают — дай статистику, что там у них выросло и где.
Первый же подсчет в лоб — количество документов и количество строк в них — показал, что документооборот не вырос.
Ладно, думаю, может там что-то усложнилось в документах, реально может труднее стало их оформлять.
Смотрю «средний чек» и его динамику по двум бухгалтерам — нет, вроде не растет, не падает.
Тут дошло — недавно ушла в декрет давно работавшая девушка-бухгалтер, на его место взяли двух новых. Данные у меня были по всем трем, сравниваю — ба, вот оно. Два новых бухгалтера вводят документы медленнее, чем один старый.
Все, расширение штата отменилось, надо просто подождать, пока набьют руку. Заодно — немножно автоматизировать.
Из третьего примера следует четвертый, уже позитивный. Видя динамику «среднего чека» по типам объектов, мы стали ее использовать для анализа автоматизированности операций и последствий вносимых изменений. Если «средний чек» подрастал, то анализировали причины, наблюдали за людьми вживую и улучшали.
Запись значений показателей
Технически это очень простое решение. Суть его проста — пишется запрос, который вычисляет какую-то цифру и сохраняет ее в системе с нужной периодичностью. В итоге имеем динамику по времени для цифры.
Многие цифры запоминать не нужно, т.к. они воспроизводимы. Например, нет нужды запоминать объем продаж — его всегда можно посмотреть ретроспективно.
Но некоторые цифры можно воспроизвести, только подняв бэкап базы. Например, только так можно узнать, сколько у вас было отрицательных остатков по товарам месяц назад. Кто читал предыдущие мои статьи, понимает, что речь об Айсберге.
Первый пример использования. Есть проблемы с зачетом аванса — достаточно большая сумма висит одновременно на 60.01 и 60.02. Функционал типовой, методических трудностей нет — просто укажи правильную аналитику в документах, и аванс зачтется. На совещаниях бухгалтерия говорит — нет проблем, сделаем. На каждом следующем совещании повторяет — делаем, там много работы, автоматизировано плохо. На меня смотрят косо.
Прихожу, включаю запись показателя — суммы незачтенного аванса. Думаю — нет, отмажутся, скажут что незачтенный аванс растет быстрее, чем они его исправляют. Делю показатель на три части — сумма на начало года, сумма на начало месяца, сумма на сегодня.
На следующем совещании показываю цифры — как было и как стало. Незачтенный аванс на начало года и начало месяца стоит колом — ничего не исправляли. Незачтенный аванс на сегодня почти не изменился — значит, сейчас документы нормально оформляют. В итоге старые ошибки исправили за 2 дня.
Второй пример использования. Автоматизировали снабженцев, функция простая — программа говорит, сколько чего надо заказать у поставщиков, бери и заказывай. Отдельно, указанный механизм пишет уровень текущий дефицитов. Смотрим — по одним позициям дефицит уменьшается, по другим растет. За позиции отвечают разные люди. На совещании все говорят — да-да, все делаем как велено, смотрим, заказываем. Почему дефициты растут — не знаем, наверное автоматизация плохая, цифры неверно посчитаны. Все косо смотрят на меня.
Иду в лоб — смотрю оформленные заказы поставщикам. Сходу разобраться не удается, т.к. документы вводятся и изменяются не оперативно — это нормально, т.к. процесс согласования заказа может занимать несколько дней, и он все это время корректируется.
Ставлю запись двух показателей индивидуально по каждому снабженцу — сколько каких позиций было к заказу на утро, сколько из них заказал в течение дня. И вуаля — «хороший» менеджер (аккуратная девочка) заказывал 85-100 % того, что требовала система, «плохие» — 15 %. Все, пошла работа с дисциплиной. Что интересно — снабженцы, увидев этот отчет, попросили дать его им в использование (сами снабженцы, а не их руководитель). Разница между моим и их отчетом была простой. Их отчет показывал текущие остатки, а мой еще показывал «время жизни» этих остатков. Все тот же Айсберг.
Фиксация идей
Несколько раз слышал от программистов, что у них воруют идеи, особенно начальники. Слушают идею, потом говорят, что она ни о чем, а через какое-то время выдают за свою.
У меня идей обычно много возникает, про качество судить не буду, но по факту их много. Я несколько лет назад заметил, что я их не запоминаю. Бывает, что придумываю идею по несколько раз.
Потом увидел на сайте студии Артемия Лебедева, что они записывают идеи, и считают это полезным. Решил поступить также — в системе учета задач сделал себе раздельчик, куда стал эти идеи записывать. Он был доступен только под полными правами, т.к. нужен был только мне.
Потом в компании решили систематизировать работу с рационализаторскими предложениями — подачу, оценку, учет реализации и т.д. Меня спросили, можно ли автоматизировать, я сказал — уже все автоматизировано, показал свой механизм. Немного доработал, чтобы было голосование, комментарии, учет реализации, постановка задач и т.д. Но суть не в этом.
Суть в том, что идеи стали публичными и зафиксированными, и украсть их стало сложно. Мои — почти невозможно, т.к. на момент открытия системы для пользователей там уже содержалось несколько сотен моих записей.
Первый пример использования даже не требовал моего участия. Идеи читали многие, и когда кто-то где-то высказывал предложение, читатели ему открыто говорили — а, была такая идея, посмотри в системе, там и обсуждение есть. Если я не присутствовал в этом разговоре, то выдумщика присылали ко мне, и обычно он начинал фразу с «ты вот идею такую предлагал, я почитал, она интересная, давай реализуем...».
Второй пример связан с продвижением системы рационализаторских предложений. К функционалу фиксации идей я, естественно, прицепил отслеживание прочтения. И получалось так, что сотрудники некоторых отделов, реально стремившиеся изменить свою работу к лучшему, начали вносить свои предложения в систему. Но реализовывались только предложения, связанные с автоматизацией, т.к. они адресовались мне, а мне это было интересно.
На совещаниях руководителям задавался вопрос — как у вас с реализацией предложений? Есть полезные идеи от ваших сотрудников? Многие дружно отвечали — не, ничего интересного, ерунда всякая. Показываю отчет — в систему вообще не заходили, ни одной идеи не прочитали, не говоря уж о реализации. На всякий случай переспросили у сотрудников — может вы устно или по почте свои предложения даете руководителям? Нет, говорят, отродясь такого не было, и вообще боимся голову поднять.
Данные предоставили, процесс сдвинулся с мертвой точки.
Фиксация данных
Цель этого механизма — расширить возможности версионирования. Обычно версионирование (как типовое, так и не типовое) фиксирует изменения первичных данных — справочников, документов и т.д. В реальной практике этого бывает недостаточно.
Например, «слетела оборотка» с разными вариациями «слетания». Традиционный путь — либо смотреть изменения документов, которые могли повлиять, либо поднимать бэкап, выгружать детализацию в эксель и сравнивать обороты.
Проблема еще в том, что момент «слетания оборотки» должен отслеживать человек.
В итоге сделал несложный механизм, который красиво хранит свернутую структуру оборотов и реагирует на изменения. И область данных, которую фиксировать, и свертка, и периодичность — настраивается через запрос.
Не вдаваясь в детали, механизм сигнализировал об изменениях области данных («слетела оборотка») в течение часа (это периодичность срабатывания регл.задания), указывал область данных, указывал период, и давал возможность найти первичные данные.
Да, и позволял «принять изменения» — если все было честно, то измененные данные становились эталонными, и слежка шла уже за изменениями.
Первый пример использования. Люди стали жаловаться на скачки остатков на складе («утром смотрю — 10 шт, в обед смотрю — 5 шт, а я уже клиенту пообещал, а я не дурак, вижу что движений не было неделю»). Бухгалтерия говорит — мы ни при чем, все документы оформляются в течение суток, никаких исправлений задним числом. Смотрим в механизм — вуаля, остатки сегодня меняются, потому что изменились обороты за предыдущий месяц. Ковыряем — бухгалтер ввел новый документ месячной давности. Спрашиваем — ты чего? Не успеваю, говорит.
Второй пример использования. Я фиксировал данные о продажах — просто потому, что на этой области данных тестировал механизм. Считалось, что данные о продажах меняются максимум неделю, и то в редких случаях, когда допущены ошибки. А тут смотрю — изменились продажи прошлого месяца. Сами понимаете, за прошлый месяц менеджер по продажам уже премию получил. Вижу, что бухгалтер изменил — ты чего, говорю? Оказалось, менеджер заставил, потому что сам перемудрил, клиента запутал. После этого случая бухгалтер так делать перестал.
Вопросы для контроля
Функционал контроля задач, проектов и т.д. есть, например, в 1С: Документообороте, наверняка многие видели. Там вы можете любой (или почти любой) объект поставить на контроль, установить дату, и у вас выскочит напоминание.
Мне типовой не понравился, т.к. он не позволяет делать контроль многоэтапным — например, сделать так, чтобы напоминание выскочило 10 раз с периодичностью в неделю. Поэтому я сделал свой простецкий механизм, основное отличие которого — он позволяет вести историю контроля, и растягивать его на какой угодно срок.
Например, я инициирую изменение в бизнес-процессах. Пишу соответствующие письма, провожу встречи и т.д. Записываю себе в систему этот вопрос, ставлю точку контроля — через неделю, пишу комментарий типа «переспросить Васю». Через неделю вижу напоминание, переспрашиваю Васю, Вася говорит «ааа, слушай, у нас завал, пока некогда». Ок, говорю, ставлю следующую точку — через неделю. Вижу напоминание, захожу — вижу историю. Переспрашиваю Васю, у Васи опять завал. Говорю — Вася, ты это уже говорил. Вася клянется, что это было в последний раз. Через неделю движение все-таки начинается.
Выглядит, как ерунда какая-то банальная, и вроде все это почтой можно разрулить, но, как сказано в начале статьи, на истину не претендую. Применение этого инструмента и подхода несколько раз меня выручало, когда банально нужно добиться чего-то от людей, которые тебе не подчиняются. Поставить задачу ты им не можешь, а идти через верх в данной конкретной ситуации не по-пацански — люди вообще ничего делать не будут.
Учет затрат на автоматизацию
Технически это очень просто. Есть учет задач и проектов в системе. В каждой задаче есть некая оценка трудозатрат — либо часы, либо баллы по покеру планирования. Зарплату программистов мы знаем. Заказчик, его подразделение и руководитель известны.
Берем зарплату программиста и распределяем на решенные за месяц задачи. Получается стоимость решения конкретной задачи. Можно собрать по проекту, по заказчику, по подразделению.
Первый пример использования — защита от наездов типа «нами не занимаются, наши задачи не решают». Открываем отчет, смотрим — ага, на автоматизацию бухгалтерии компания потратила 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 не принесло ничего, вообще. Создание сайта, взамен предыдущего, не принесло никакого эффекта.
Вся автоматизация бухгалтерии приносила только отрицательный эффект, особенно на численность их штата, несмотря на все наши усилия по сдерживанию этой раковой опухоли компании.
А вот автоматизация экономистов, ведущих бухгалтерский учет, сказалась позитивно — мы лишились двух сотрудников. Их не увольняли — они сами ушли, по своим причинам. Но мы предложили — давайте пока не брать новых, посмотрим, как пойдет, мы там много автоматизировали. Директор согласился, и все получилось.
После посчитанной корреляции руководство стало иначе смотреть на автоматизацию. Ну и на программистов, разумеется. Особенно в свете того, что нам расчет этой корреляции никто не заказывал — это была наша инициатива.
Правда, потом директор сменился, и все пришлось начинать с самого начала. Но, где-то через полгода, новый директор тоже оценил расчет корреляции.
