Каталог решений - Экзорцизм программистскими методами

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

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

В наличии

Примеры из жизни о том, как инструменты на платформе 1С помогают компании изгонять зло.

Категория:

Описание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если будет интересно, воспроизведу и выложу.

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

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

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

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

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

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

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

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

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

has been added to your cart:
Оформление заказа