Все знают, что такое айсберг – большой кусок льда, который плавает в океане. Все помнят, что не так с айсбергом – видна лишь небольшая его часть, которая над поверхностью воды, остальное скрыто. И сколько его там, этого остального – никто не знает.
Аналогичная ситуация – с данными в автоматизированных системах.
Мы, обычно, видим сами данные. Документы, вроде накладных на отгрузку или поступление, перемещения, платежки и т.д. Справочники – номенклатуру, контрагентов, подразделения. Задачи видим, и обычные, и процессные. Остатки видим – сколько лежит товаров на складе, кто нам денег должен, сколько у нас дефицитов и т.д.
Любые данные, по отдельности или в совокупности, образуют некое состояние. Например, склад у нас, в каждый момент времени, находится в некотором состоянии. Мы так и говорим – состояние склада. Или состояние дебиторской задолженности, или кредиторской, или состояние задач, или состояние процессов.
Мгновенно оценить состояние мы вполне способны – и в автоматизированной системе, и в жизни. Оценили, убежали и забыли.
Потом, через какое-то время, нам на глаза снова попадаются те же данные, или ситуация. Мы снова делаем мгновенную оценку состояния – говорим «все хорошо» или «все плохо». Так повторяется второй, третий, сто двадцать пятый раз.
Если мы оцениваем ситуацию, как критическую, то, наверное, как-то будем ее исправлять. А если нет? Да, ситуация не очень хорошая, но вроде жить можно. Так часто бывает на оперативных совещаниях – кто-то поднимает вопрос, рассказывает ситуацию, дает оценку. Все охают, или цокают языками и… что? Как правило – забывают. До следующего раза, пока снова кто-то не обратит внимание.
Негативная ситуация каждый раз получает индульгенцию, потому что мы видим ее, будто в первый раз. Кто-то, конечно, припоминает – о, это ведь уже было, не помню, вроде месяц назад, или может полгода. На обладателя слишком хорошей памяти цыкают, чтоб молчал – пусть лучше ситуация считается чистой, как младенец.
Почему так происходит? Чего не хватает в информации о негативной ситуации? Мгновенная оценка есть, достаточно качественная и детальная. Как продолжить фразу «вот тут все плохо», чтобы она заиграла новыми красками, и стала более информативной?
Продолжить фразу очень просто: «вот тут все плохо, и уже давно». Время, или длительность состояния – та информация, которая нужна для адекватного принятия решения.
В жизни это всем понятно. Приведу пару примеров.
«Мне не хватает денег» — мгновенная оценка, требует оперативного вмешательства. «Мне не хватает денег уже год» — ого, да у нас тут системная проблема, над которой надо крепко подумать и что-то менять в жизни.
«Нога что-то болит» — ну, мало ли, отсидел может, или погода на артрит влияет. «Нога что-то уже полгода болит» — срочно беги в поликлинику.
«Ребенок принес двойку» — молодец, давно пора, двойки нужны для равновесия. «Ребенок всю четверть приносит одни двойки» — ах ты дебил малолетний, чем ты там занимаешься, завтра же в школу иду, где там телефон твоего классного руководителя.
Аналогично в бизнес-системах.
«Клиент должен нам миллион» — ну ладно, заплатит, чего пристаешь. «Клиент должен нам миллион уже полгода» — твою ж мать, а ты куда смотрел?
«В дефицитной ведомости пять срочных позиций» — закажут снабженцы, чего зря людей дергать. «В дефицитной позиции уже два месяца висят пять срочных позиций» — так вот из-за кого продажи падают! Срочно тащи всех на ковер, немедленно закупить!
«Программисты мою задачу просрочили» — да они все задачи так, не парься. Сделают. «Программисты мою задачу уже на два месяца просрочили» — блин, давно хочу этих засранцев разогнать, чем они там вообще занимаются?
Как видите, длительность состояния, особенно негативного, придает информации новое измерение. Как будто была плоская, скучная информация, с которой непонятно что надо делать, а получилась трехмерная картина. Анализ ситуации и принятие решения становится намного проще.
Тут все настолько очевидно, что даже не верится – неужели такие банальности стоят отдельной главы учебника? Чтобы ответить на этот вопрос, загляните в свою информационную систему.
Много найдете состояний с измеренной длительностью? Традиционно присутствуют два отчета по принципу «Айсберг»: неликвиды и просроченная задолженность. У вас, кстати, видны неликвиды? Не во всех, даже распространенных системах, неликвиды можно увидеть.
К сожалению, в информационных системах даже понятия «состояние» нет. Присутствуют данные и средства их просмотра, под разными углами. Шикарный простор для аналитика, который любит ковыряться в больших массивах цифр, но мало толковой информации для принятия решений. Причем, не важно, кто решение принимает – человек или сама система.
Способов реализации принципа «Айсберг» несколько. Традиционный – партионный учет, когда в массив информации добавляется разделитель – документ партии. Например, пришел товар на склад – мы запоминаем не только номенклатуру и количество, но и документ прихода – накладную. У накладной есть дата, и по ней мы всегда можем вычислить срок остатка. Аналогично поступают, например, с дебиторской задолженностью – хранят не только контрагента и сумму, но и документ, который эту задолженность создал – например, накладную на отгрузку, или авансовую платежку поставщику.
В техническом плане документ партии создает много трудностей.
Во-первых, он увеличивает количество записей в таблицах. Одна запись «Втулка, 10 штук» может превратиться в десять записей – «Втулка 1 шт от 01.09.2017», «Втулка 1 шт от 09.12.2017» и т.д.
Во-вторых, необходимы алгоритмы списания партий. Например, при отгрузке (т.е. списании товара) нужно знать, с какой партии минусовать остаток. Или при оплате от покупателя нужно указывать, за какой документ отгрузки пришли деньги. Подхода используется два: либо автоматическое вычисление партий, либо ручное их указание. Автоматический выбор партии – это известные стратегии списания FIFO (сначала – самая ранняя партия) и LIFO (сначала – самая поздняя партия). Ручное указание партий обычно используется в разнесении платежей.
Третья проблема, скорее, методическая – реальная жизнь не подчиняется алгоритму списания партий. Кладовщик возьмет с полки деталь, но не ту, которую выбрала программа. Он ведь не знает, что такое FIFO.
Получается технически сложная система, результатами работы которой пользуются редко. Я не говорю сейчас о бухгалтерском или управленческом учете, который использует партии для расчета стоимости списания. Я говорю об измерении длительности негативного состояния – неликвидов. Много ли вам приходилось видеть реально, регулярно и результативно работающих процессов по неликвидам?
Второй способ – не хранить длительность всех состояний, а вычислять ее при необходимости. Это мгновенная оценка длительности. Например, так можно найти неликвиды на складе, не храня партии. Способов много – например, понимая текущие остатки, ретроспективно посмотреть на движения товаров. Если движений не было, то перед нами – неликвид.
Такой способ лишен недостатков партионного учета – не требует хранения больших объемов данных и не усложняет текущую работу. Но и главного достоинства партионного учета – хранения длительности – в нем нет. Вы видите оценку длительности только мгновенно, в конкретный момент времени. Зашли, посмотрели, оценили, вышли – оценка длительности исчезла.
С одной стороны – ладно, ничего страшного. Можно брать алгоритм вычисления длительности, и встраивать в процессы — пусть система реагирует, когда негативное состояние затянулось. Но, увы, мгновенная оценка длительности не такая уж и мгновенная – ресурсы системы на вычисление тратятся так, что только шум стоит, каждую минуту не набегаешься.
Мгновенную оценку длительности можно использовать – для не очень важных процессов, которые не надо контролировать каждый день. Например, те же неликвиды, когда вы выстраиваете процесс избавления от них – раз в месяц делаете вычисления, определяете список самых залежавшихся позиций, формируете задачу избавления от них (например, продажи с дисконтом или сдачи в металлолом).
Третий способ – вычислять, отделять, хранить и отслеживать купированное состояние.
Например, есть у вас дефицитная ведомость – список товаров, которые нужно закупить. Для производства, продаж, ремонтов и т.д. Нет смысла следить за всей дефицитной ведомостью – достаточно просроченных позиций. Вот эти просроченные позиции и стоит выделить, их ведь не будет много?
Просто сохраняете в отдельном месте системы список просроченных позиций, с количествами и, главное, датой возникновения. Там ведь не всегда есть просроченные позиции? Как только появились – запоминаете, и дата появления будет точкой отсчета длительности.
Дальше система делает все сама. Периодически просматривает дефицитку – проверяет, есть ли просроченные позиции. Если нет – отлично, значит негативное состояние прекратилось. Сохраненный список просроченных позиций можно забыть и удалить из системы (тут на ваше усмотрение, можете оставить на память, т.е. для ретроспективного анализа или системы мотивации). Если же просроченные позиции в дефицитке все еще присутствуют – тоже хорошо (для системы), потому что делать ничего не надо, часики тикают, длительность нарастает.
Человек, который присматривает за просрочкой в дефицитке, будет просто счастлив. Во-первых, ему можно больше не присматривать – достаточно настроить уведомление о появлении просрочки. Во-вторых, больше не надо разбираться, давно ли просрочка появилась – длительность будет показана автоматически. В-третьих, не надо отслеживать момент исчезновения просрочки – система сообщит, когда дела пойдут на лад.
Вам, как бизнес-программисту, будет намного проще выстраивать процессы реагирования в бизнес-системе. Пока нет понимания длительности, вы вынуждены дергать человека сразу, как только негативное состояние возникло. И ваше «дерганье» будет висеть постоянно перед носом, как красная тряпка.
Когда же есть длительность, настройка становится более тонкой – вы сами выбираете момент, когда показать человеку проблему. Цветовую индикацию тоже можете выбирать исходя из длительности негативного состояния. Например, желтая – один день, красная – два и более дня, и т.д.
Заодно и систему восходящего реагирования можете выстроить. Например, сначала просрочку в дефицитке показывать снабженцу. Через сутки, если не устранил – начальнику снабжения. Через трое суток – коммерческому директору. Через неделю – директору.
Причем, вы понимаете: от уровня, на который поднялась задача, зависит сама ее суть. Снабженца вы просите устранить просрочку – он должен заказать позиции. Начальника снабжения вы просите обратить внимание и, возможно, передать позиции другому снабженцу. Директору вы говорите, что вся служба снабжения как-то странно работает, нужны системные изменения.
Ключевые признаки этого способа: отдельное хранение данных о состоянии и автоматическая их актуализация. Технически реализуется с помощью принципа «Автозадачи», который будет рассмотрен далее.
В процессе работы вы наверняка обнаружите другие способы определения длительности состояния, т.е. величины подводной части айсберга. Возможно, вы программируете в таких системах, где перечисленные мной способы не работают – тогда придется искать свои.
Главное – не забывайте о принципе «Айсберг», когда программируете бизнес-систему.
Особенно, если хотите использовать партионный учет – его нужно закладывать еще при проектировании, ретроспективно он разворачивается с большим трудом.
Мгновенную же оценку длительности, как и «Автозадачи», можно включить в любой момент. Ну и выключить тоже. В этой легкости – их преимущество.
Приведу несколько примеров использования Айсберга из своей практики.
Первый пример – системы управления задачами. Вот есть задача, или поручение, или служебная записка. Там есть инициатор, есть исполнитель. Когда задача принята в работу, все понятно – есть срок исполнения, и можно быстро определять, все с задачей хорошо, или нет.
Но есть у задачи и некие промежуточные состояния. Например, инициатор ее написал, отправил, а исполнитель должен принять в работу. Принятие в работу – это некий признак внутри задачи. Пока исполнитель его не проставит, состояние задачи – это подводная часть айсберга. Ни черта не понятно, когда он, наконец, соизволит это сделать.
Я поступил просто – добавил дату принятия в работу отдельным полем в задачу. Принял – дата запомнилась. А дата отправки задачи исполнителю и так есть. Соответственно, мы получаем две длительности негативного состояния. Пока задача не принята в работу, длительность равна разнице между текущей датой и датой отправки. Когда, все-таки, исполнитель ее принял, появляется точный интервал между принятием и отправкой, который навсегда запоминается в системе и используется для дальнейшего анализа.
Аналогичная ситуация, с непонятной длительностью, возникает, когда исполнитель сделал работу, и отправил инициатору на проверку. Когда он там проверит – не известно. Любой приличный программист, работающий напрямую с конечным пользователем, подтвердит – задачи очень часто зависают на проверке. Причем, физически она может быть уже проверена, пользователю все нравится, но он не удосуживается зайти в систему и сделать отметку.
Решение – аналогичное. Добавляем две даты в задачу – когда исполнитель отправил на проверку, и когда инициатор прореагировал – принял результат или вернул на доработку. Соответственно, длительность состояния проверки у нас всегда под рукой, и мы можем нормировать время проверки задачи. Ну, чтоб не повадно было.
Мой любимый пример – закупки. С задачами все просто – там всегда есть некий объект, в котором эта самая задача записана, и можно к этому объекту добавлять поля, хранящие данные о длительности состояния.
А закупки – это поток. Там никто, в здравом уме, не будет ставить никаких отдельных задач. Ну сами представьте – сидит девочка, заказывает втулки. Каждый день. Одни и те же втулки. А еще валы, болты, гайки, металл, поковки, штамповки и т.д.
Есть только информация о том, что нужно заказать. Да, она бывает разного уровня детальности – иногда просто перечень номенклатуры и количеств, иногда – в разрезе получателей, контрагентов, заказов, подразделений и т.д. Но эта информация всегда мгновенная, как вспышка. Зашел – видишь, надо 1020 штук заказать. Через минуту зашел – ого, уже 1200, потому что ситуация изменилась.
Снабженцы это понимают, и пользуются в своих интересах. На совещаниях, разборах и оперативках до закупщиков часто пытаются докопаться, но с них, как с гуся вода. Говорят им – э, ребята, а чего втулок не хватает? Так это вчера только потребность возникла! – отвечают те. Как вчера? Ну так, вчера. Клянусь, вчера утром заходил в дефицитку, там не было втулок!
Доказать, что втулки вчера были, можно, только подняв бэкап. Разумеется, живые люди не будут каждый день поднимать бэкапы, поэтому уставшие продавцы и производственники придумывают свой вариант Айсберга – распечатки. Заходят, например, в понедельник в систему, смотрят в дефицитку, и распечатывают ее. Когда возникает проблема, или терки со снабженцами, показывают им эту бумажку.
Но от такой бумажки легко увернуться. Снабженцы говорят – чего вы мне тут подсовываете? Да, в понедельник не хватало втулок, ну так и что? Уже во вторник их было столько, что всем бы хватило с избытком! А то, что вы видите в системе сегодня, возникло только вчера.
Их потом тоже заставляют участвовать в бумажных делах – не просто печатают дефицитку, а еще и дают снабженцам на подпись. И сроки поставки просят проставить. Сами понимаете, процесс по эффективности – сильно так себе.
Принцип Айсберг работал в задачах, но не работал в снабжении. Продавцы понимали, что надо что-то делать, и стали-таки ставить задачи закупкам – прям создают объект, к нему прикладывают перечень позиций, и ждут исполнения. Сначала стало получаться, потом снабженцы начали тупо отклонять такие задачи, с комментарием типа «не надо нам ставить отдельные поручения на нашу рутинную работу». В общем, правильный комментарий – если на каждый чих ставить задачу, то и уборщиц придется подключать к системе.
Проблему решили автозадачами и Айсбергом, который там включен по умолчанию. Автозадача просто сморит на дефицитку, разбивает недостающие позиции по исполнителям, и формирует некие объекты, содержащие информацию о том, что надо заказать у поставщиков. Дата формирования автозадачи фиксируется автоматически, равно как и дата исполнения, т.е. размещения позиций у поставщиков.
Если надо было, например, 100 втулок, а снабженец заказал 70, то автозадача не закрывается, а просто корректируется – теперь надо разместить 30 позиций. Что важно – дата начала негативного состояния, т.е. дефицита, остается прежней. 70 позиций человек заказал за один временной интервал, а 30 – за другой.
С применением Айсберга проблема очень быстро решилась, потому что скрыть уже ничего не получалось. Во-первых, учет длительности дефицита ведется в разрезе позиций и количеств, во-вторых – с привязкой к исполнителю. Тут же, разумеется, родился некий KPI для снабженца – какой процент позиций он заказывает в срок (кажется, он должен был в сутки уложиться, с момента возникновения потребности).
Хорошо ложится Айсберг на бухгалтерию. У тех ведь как – постоянно где-то что-то не так. Отрицательные остатки присутствуют, по самым разным счетам, или по ненавидимым ими регистрам. Авансы не зачитываются, несмотря на применение восстановления последовательности расчетов. Не говоря уже о суммовых остатках без количества, и наоборот.
В обычном состоянии системы, без Айсберга, докопаться до бухгалтерии сложно. Единственный способ доказать, что минусы висят уже месяц, это бэкап. Но они тоже не дураки – скажут, что да, месяц назад были минусы, потом мы их убрали, а сейчас опять вылезли, это вы, программисты, чего-то напутали. Если снабженцы просто отмазываются, не перекладывая проблем на других, то бухгалтеры давно придумали – не знаю, осознанно или нет – такой метод, как искусственный цейтнот.
Вот есть на предприятии приличный программист, который заботится о состоянии учета. Видит он минусы в оборотке, и говорит бухгалтерам – милые тётеньки, чего ж вы делаете, давайте устраняйте! Они сначала говорят – да, конечно, устраним, это же в наших интересах. Минусы сильно помешают нам при закрытии квартала, обязательно устраним. В этот момент – допустим, это май – никакого цейтнота, т.е. ограниченного времени на решение задачи – еще ни у кого нет. Поэтому задача наведения порядка, как и положено, откладывается в дальний ящик.
Предотвратить создание отрицательных остатков методами контроля текущей, ежедневной работы, практически невозможно. Даже если запретить списание в минус – есть ведь исправление прихода. Поэтому наш приличный программист вздыхает, и ждет.
До наступления конца июня программист, допустим, еще несколько раз напоминает бухгалтеру, что неплохо бы минусы убрать. Чем ближе срок, тем агрессивнее становится ответ – отвали, не твое дело, не учи нас работать, и, в конце концов, полное игнорирование.
И вот пришел июль, надо закрывать квартал. Теперь задачу надо решать в режиме цейтнота – максимально быстро и эффективно, потому что еще куча дел, кроме минусов. Если вы работали программистов на заводе, то знаете, что происходит в этот момент – задача быстро и красиво перекладывается с бухгалтерии на программистов.
Возмущаться уже поздно, хотя программисты и пытаются. Но бухгалтеры приводят железные аргументы – все, некогда, надо отчетность сдавать, а там таааакиииие штрафы, что компанию закрывать придется. Руководителю, модерирующему ругань программиста и бухгалтера, ничего не остается, как встать на сторону последнего – слишком реально звучит угроза. Программист там что-то ноет, вроде это работа бухгалтера, они отлично знают, что надо делать, и вообще программист обходится компании втрое дороже, чем бухгалтер, и все это неправильно, но уже поздно – искусственный цейтнот создан.
Заканчивается, обычно, так: программист соглашается-таки исправить минусы своими руками, а руководитель и бухгалтер клятвенно обещают заняться этой системной проблемой после устранения цейтнота. И так – каждый раз.
Решение проблемы – аналогичное снабжению. Делаем автозадачу на каждый вариант косяка – например, вычисляем и показываем минусы в оборотке, ставим ответственного и, главное, дату возникновения задачи, чтобы получился Айсберг. Теперь, как только минус возник, появляется автозадача, и ее можно использовать как аргумент в спорах.
Понятно, что бухгалтерия будет игнорировать эти автозадачи. Но зато появится то, чего не хватает программисту на совещаниях с руководством – факты. Вот косяк, вот дата его возникновения, вот длительность негативного состояния – месяц, допустим. Главное правильно подать информацию – смотрите, уважаемый руководитель, наш учет уже месяц находится в неуправляемом состоянии, мы понятия не имеем, сколько стоит наш склад, сколько мы понесли затрат, потому что у нас минусы. Сами понимаете, дорогой руководитель, дело ведь не в минусах, а в отношении к учету. Минус – это крайняя ситуация, очевидная и явная ошибка. А есть еще неявные, которые глазу не видны, но лишают вас возможности пользоваться данными. Ну и так далее.
Еще Айсберг прям просится в любые процессы, где есть согласование. Заявки на расходование денежных средств, договоры, спецификации, бюджеты, планы, выдача спец.одежды и так далее, до бесконечности.
Бюрократы любят согласования, но не как процесс, который надо делать, а как процесс, который можно бесконечно затягивать. Наивный программист, которому поставили задачу добавить в договор согласование главбуха или финансового директора, поступает просто и незатейливо – добавляет в этот самый договор некое поле, типа «Согласовано». Он не знает про Айсберг, поэтому обрекает процесс согласования договоров на медленную и мучительную смерть.
Динамить согласование будут до бесконечности, если договор – какой-нибудь не очень значимый, и не находится в поле зрения директора. А инициаторам договоров ничего не останется, как бегать периодически к главбуху, чтобы узнать, когда произойдет-таки великое таинство.
Айсберг решает проблему сразу и быстро. В данном случае достаточно знать две даты – когда отправлено на согласование, и когда оно состоялось. Длительность состояния несогласованности в этом случае вычисляется элементарно, и можно это время банально нормировать.
Я так делал с согласованием договоров, где цепочка состояла из нескольких людей – руководителя подразделения, финансиста, бухгалтера и юриста. Каждому были отведены сутки на согласование, и Айсберг довел процент попадания в этот срок до 90 %.
Потом, правда, началась проблема с другой стороны – когда договор согласован и подписан на бумаге, оба экземпляра отправляются контрагенту, чтобы он свои подпись и печать поставил. Соответственно, бумажка потом должна вернуться обратно, чтобы попасть в архив юридического отдела.
Но люди, жаловавшиеся ранее на долгое согласование, не спешили сдавать оригиналы договоров юристам. Они вообще об этом забывали – им достаточно того, что договор подписан, и можно с контрагентом работать. Тут взвыли юристы – нельзя без оригиналов, любая проверка устроит компании такой Освенцим, что мало не покажется.
Соответственно, появился еще один Айсберг, для сдачи оригиналов договоров. Отвели месяц для обычных, и 100 дней для ВЭД-договоров. И все, заработало. Особенно, когда юристы стали отклонять новые договоры, пока старые не сданы. Картинка о количестве и сроках несданных договоров была постоянно доступна в системе, и, ввиду важности этого вопроса, была на постоянном контроле руководства. Никому не хочется слишком часто попадать в сферу интересов директора, поэтому сдавали оригиналы почти всегда вовремя.
Аналогичная ситуация – с данными в автоматизированных системах.
Мы, обычно, видим сами данные. Документы, вроде накладных на отгрузку или поступление, перемещения, платежки и т.д. Справочники – номенклатуру, контрагентов, подразделения. Задачи видим, и обычные, и процессные. Остатки видим – сколько лежит товаров на складе, кто нам денег должен, сколько у нас дефицитов и т.д.
Любые данные, по отдельности или в совокупности, образуют некое состояние. Например, склад у нас, в каждый момент времени, находится в некотором состоянии. Мы так и говорим – состояние склада. Или состояние дебиторской задолженности, или кредиторской, или состояние задач, или состояние процессов.
Мгновенно оценить состояние мы вполне способны – и в автоматизированной системе, и в жизни. Оценили, убежали и забыли.
Потом, через какое-то время, нам на глаза снова попадаются те же данные, или ситуация. Мы снова делаем мгновенную оценку состояния – говорим «все хорошо» или «все плохо». Так повторяется второй, третий, сто двадцать пятый раз.
Если мы оцениваем ситуацию, как критическую, то, наверное, как-то будем ее исправлять. А если нет? Да, ситуация не очень хорошая, но вроде жить можно. Так часто бывает на оперативных совещаниях – кто-то поднимает вопрос, рассказывает ситуацию, дает оценку. Все охают, или цокают языками и… что? Как правило – забывают. До следующего раза, пока снова кто-то не обратит внимание.
Негативная ситуация каждый раз получает индульгенцию, потому что мы видим ее, будто в первый раз. Кто-то, конечно, припоминает – о, это ведь уже было, не помню, вроде месяц назад, или может полгода. На обладателя слишком хорошей памяти цыкают, чтоб молчал – пусть лучше ситуация считается чистой, как младенец.
Почему так происходит? Чего не хватает в информации о негативной ситуации? Мгновенная оценка есть, достаточно качественная и детальная. Как продолжить фразу «вот тут все плохо», чтобы она заиграла новыми красками, и стала более информативной?
Продолжить фразу очень просто: «вот тут все плохо, и уже давно». Время, или длительность состояния – та информация, которая нужна для адекватного принятия решения.
В жизни это всем понятно. Приведу пару примеров.
«Мне не хватает денег» — мгновенная оценка, требует оперативного вмешательства. «Мне не хватает денег уже год» — ого, да у нас тут системная проблема, над которой надо крепко подумать и что-то менять в жизни.
«Нога что-то болит» — ну, мало ли, отсидел может, или погода на артрит влияет. «Нога что-то уже полгода болит» — срочно беги в поликлинику.
«Ребенок принес двойку» — молодец, давно пора, двойки нужны для равновесия. «Ребенок всю четверть приносит одни двойки» — ах ты дебил малолетний, чем ты там занимаешься, завтра же в школу иду, где там телефон твоего классного руководителя.
Аналогично в бизнес-системах.
«Клиент должен нам миллион» — ну ладно, заплатит, чего пристаешь. «Клиент должен нам миллион уже полгода» — твою ж мать, а ты куда смотрел?
«В дефицитной ведомости пять срочных позиций» — закажут снабженцы, чего зря людей дергать. «В дефицитной позиции уже два месяца висят пять срочных позиций» — так вот из-за кого продажи падают! Срочно тащи всех на ковер, немедленно закупить!
«Программисты мою задачу просрочили» — да они все задачи так, не парься. Сделают. «Программисты мою задачу уже на два месяца просрочили» — блин, давно хочу этих засранцев разогнать, чем они там вообще занимаются?
Как видите, длительность состояния, особенно негативного, придает информации новое измерение. Как будто была плоская, скучная информация, с которой непонятно что надо делать, а получилась трехмерная картина. Анализ ситуации и принятие решения становится намного проще.
Тут все настолько очевидно, что даже не верится – неужели такие банальности стоят отдельной главы учебника? Чтобы ответить на этот вопрос, загляните в свою информационную систему.
Много найдете состояний с измеренной длительностью? Традиционно присутствуют два отчета по принципу «Айсберг»: неликвиды и просроченная задолженность. У вас, кстати, видны неликвиды? Не во всех, даже распространенных системах, неликвиды можно увидеть.
К сожалению, в информационных системах даже понятия «состояние» нет. Присутствуют данные и средства их просмотра, под разными углами. Шикарный простор для аналитика, который любит ковыряться в больших массивах цифр, но мало толковой информации для принятия решений. Причем, не важно, кто решение принимает – человек или сама система.
Способов реализации принципа «Айсберг» несколько. Традиционный – партионный учет, когда в массив информации добавляется разделитель – документ партии. Например, пришел товар на склад – мы запоминаем не только номенклатуру и количество, но и документ прихода – накладную. У накладной есть дата, и по ней мы всегда можем вычислить срок остатка. Аналогично поступают, например, с дебиторской задолженностью – хранят не только контрагента и сумму, но и документ, который эту задолженность создал – например, накладную на отгрузку, или авансовую платежку поставщику.
В техническом плане документ партии создает много трудностей.
Во-первых, он увеличивает количество записей в таблицах. Одна запись «Втулка, 10 штук» может превратиться в десять записей – «Втулка 1 шт от 01.09.2017», «Втулка 1 шт от 09.12.2017» и т.д.
Во-вторых, необходимы алгоритмы списания партий. Например, при отгрузке (т.е. списании товара) нужно знать, с какой партии минусовать остаток. Или при оплате от покупателя нужно указывать, за какой документ отгрузки пришли деньги. Подхода используется два: либо автоматическое вычисление партий, либо ручное их указание. Автоматический выбор партии – это известные стратегии списания FIFO (сначала – самая ранняя партия) и LIFO (сначала – самая поздняя партия). Ручное указание партий обычно используется в разнесении платежей.
Третья проблема, скорее, методическая – реальная жизнь не подчиняется алгоритму списания партий. Кладовщик возьмет с полки деталь, но не ту, которую выбрала программа. Он ведь не знает, что такое FIFO.
Получается технически сложная система, результатами работы которой пользуются редко. Я не говорю сейчас о бухгалтерском или управленческом учете, который использует партии для расчета стоимости списания. Я говорю об измерении длительности негативного состояния – неликвидов. Много ли вам приходилось видеть реально, регулярно и результативно работающих процессов по неликвидам?
Второй способ – не хранить длительность всех состояний, а вычислять ее при необходимости. Это мгновенная оценка длительности. Например, так можно найти неликвиды на складе, не храня партии. Способов много – например, понимая текущие остатки, ретроспективно посмотреть на движения товаров. Если движений не было, то перед нами – неликвид.
Такой способ лишен недостатков партионного учета – не требует хранения больших объемов данных и не усложняет текущую работу. Но и главного достоинства партионного учета – хранения длительности – в нем нет. Вы видите оценку длительности только мгновенно, в конкретный момент времени. Зашли, посмотрели, оценили, вышли – оценка длительности исчезла.
С одной стороны – ладно, ничего страшного. Можно брать алгоритм вычисления длительности, и встраивать в процессы — пусть система реагирует, когда негативное состояние затянулось. Но, увы, мгновенная оценка длительности не такая уж и мгновенная – ресурсы системы на вычисление тратятся так, что только шум стоит, каждую минуту не набегаешься.
Мгновенную оценку длительности можно использовать – для не очень важных процессов, которые не надо контролировать каждый день. Например, те же неликвиды, когда вы выстраиваете процесс избавления от них – раз в месяц делаете вычисления, определяете список самых залежавшихся позиций, формируете задачу избавления от них (например, продажи с дисконтом или сдачи в металлолом).
Третий способ – вычислять, отделять, хранить и отслеживать купированное состояние.
Например, есть у вас дефицитная ведомость – список товаров, которые нужно закупить. Для производства, продаж, ремонтов и т.д. Нет смысла следить за всей дефицитной ведомостью – достаточно просроченных позиций. Вот эти просроченные позиции и стоит выделить, их ведь не будет много?
Просто сохраняете в отдельном месте системы список просроченных позиций, с количествами и, главное, датой возникновения. Там ведь не всегда есть просроченные позиции? Как только появились – запоминаете, и дата появления будет точкой отсчета длительности.
Дальше система делает все сама. Периодически просматривает дефицитку – проверяет, есть ли просроченные позиции. Если нет – отлично, значит негативное состояние прекратилось. Сохраненный список просроченных позиций можно забыть и удалить из системы (тут на ваше усмотрение, можете оставить на память, т.е. для ретроспективного анализа или системы мотивации). Если же просроченные позиции в дефицитке все еще присутствуют – тоже хорошо (для системы), потому что делать ничего не надо, часики тикают, длительность нарастает.
Человек, который присматривает за просрочкой в дефицитке, будет просто счастлив. Во-первых, ему можно больше не присматривать – достаточно настроить уведомление о появлении просрочки. Во-вторых, больше не надо разбираться, давно ли просрочка появилась – длительность будет показана автоматически. В-третьих, не надо отслеживать момент исчезновения просрочки – система сообщит, когда дела пойдут на лад.
Вам, как бизнес-программисту, будет намного проще выстраивать процессы реагирования в бизнес-системе. Пока нет понимания длительности, вы вынуждены дергать человека сразу, как только негативное состояние возникло. И ваше «дерганье» будет висеть постоянно перед носом, как красная тряпка.
Когда же есть длительность, настройка становится более тонкой – вы сами выбираете момент, когда показать человеку проблему. Цветовую индикацию тоже можете выбирать исходя из длительности негативного состояния. Например, желтая – один день, красная – два и более дня, и т.д.
Заодно и систему восходящего реагирования можете выстроить. Например, сначала просрочку в дефицитке показывать снабженцу. Через сутки, если не устранил – начальнику снабжения. Через трое суток – коммерческому директору. Через неделю – директору.
Причем, вы понимаете: от уровня, на который поднялась задача, зависит сама ее суть. Снабженца вы просите устранить просрочку – он должен заказать позиции. Начальника снабжения вы просите обратить внимание и, возможно, передать позиции другому снабженцу. Директору вы говорите, что вся служба снабжения как-то странно работает, нужны системные изменения.
Ключевые признаки этого способа: отдельное хранение данных о состоянии и автоматическая их актуализация. Технически реализуется с помощью принципа «Автозадачи», который будет рассмотрен далее.
В процессе работы вы наверняка обнаружите другие способы определения длительности состояния, т.е. величины подводной части айсберга. Возможно, вы программируете в таких системах, где перечисленные мной способы не работают – тогда придется искать свои.
Главное – не забывайте о принципе «Айсберг», когда программируете бизнес-систему.
Особенно, если хотите использовать партионный учет – его нужно закладывать еще при проектировании, ретроспективно он разворачивается с большим трудом.
Мгновенную же оценку длительности, как и «Автозадачи», можно включить в любой момент. Ну и выключить тоже. В этой легкости – их преимущество.
Приведу несколько примеров использования Айсберга из своей практики.
Первый пример – системы управления задачами. Вот есть задача, или поручение, или служебная записка. Там есть инициатор, есть исполнитель. Когда задача принята в работу, все понятно – есть срок исполнения, и можно быстро определять, все с задачей хорошо, или нет.
Но есть у задачи и некие промежуточные состояния. Например, инициатор ее написал, отправил, а исполнитель должен принять в работу. Принятие в работу – это некий признак внутри задачи. Пока исполнитель его не проставит, состояние задачи – это подводная часть айсберга. Ни черта не понятно, когда он, наконец, соизволит это сделать.
Я поступил просто – добавил дату принятия в работу отдельным полем в задачу. Принял – дата запомнилась. А дата отправки задачи исполнителю и так есть. Соответственно, мы получаем две длительности негативного состояния. Пока задача не принята в работу, длительность равна разнице между текущей датой и датой отправки. Когда, все-таки, исполнитель ее принял, появляется точный интервал между принятием и отправкой, который навсегда запоминается в системе и используется для дальнейшего анализа.
Аналогичная ситуация, с непонятной длительностью, возникает, когда исполнитель сделал работу, и отправил инициатору на проверку. Когда он там проверит – не известно. Любой приличный программист, работающий напрямую с конечным пользователем, подтвердит – задачи очень часто зависают на проверке. Причем, физически она может быть уже проверена, пользователю все нравится, но он не удосуживается зайти в систему и сделать отметку.
Решение – аналогичное. Добавляем две даты в задачу – когда исполнитель отправил на проверку, и когда инициатор прореагировал – принял результат или вернул на доработку. Соответственно, длительность состояния проверки у нас всегда под рукой, и мы можем нормировать время проверки задачи. Ну, чтоб не повадно было.
Мой любимый пример – закупки. С задачами все просто – там всегда есть некий объект, в котором эта самая задача записана, и можно к этому объекту добавлять поля, хранящие данные о длительности состояния.
А закупки – это поток. Там никто, в здравом уме, не будет ставить никаких отдельных задач. Ну сами представьте – сидит девочка, заказывает втулки. Каждый день. Одни и те же втулки. А еще валы, болты, гайки, металл, поковки, штамповки и т.д.
Есть только информация о том, что нужно заказать. Да, она бывает разного уровня детальности – иногда просто перечень номенклатуры и количеств, иногда – в разрезе получателей, контрагентов, заказов, подразделений и т.д. Но эта информация всегда мгновенная, как вспышка. Зашел – видишь, надо 1020 штук заказать. Через минуту зашел – ого, уже 1200, потому что ситуация изменилась.
Снабженцы это понимают, и пользуются в своих интересах. На совещаниях, разборах и оперативках до закупщиков часто пытаются докопаться, но с них, как с гуся вода. Говорят им – э, ребята, а чего втулок не хватает? Так это вчера только потребность возникла! – отвечают те. Как вчера? Ну так, вчера. Клянусь, вчера утром заходил в дефицитку, там не было втулок!
Доказать, что втулки вчера были, можно, только подняв бэкап. Разумеется, живые люди не будут каждый день поднимать бэкапы, поэтому уставшие продавцы и производственники придумывают свой вариант Айсберга – распечатки. Заходят, например, в понедельник в систему, смотрят в дефицитку, и распечатывают ее. Когда возникает проблема, или терки со снабженцами, показывают им эту бумажку.
Но от такой бумажки легко увернуться. Снабженцы говорят – чего вы мне тут подсовываете? Да, в понедельник не хватало втулок, ну так и что? Уже во вторник их было столько, что всем бы хватило с избытком! А то, что вы видите в системе сегодня, возникло только вчера.
Их потом тоже заставляют участвовать в бумажных делах – не просто печатают дефицитку, а еще и дают снабженцам на подпись. И сроки поставки просят проставить. Сами понимаете, процесс по эффективности – сильно так себе.
Принцип Айсберг работал в задачах, но не работал в снабжении. Продавцы понимали, что надо что-то делать, и стали-таки ставить задачи закупкам – прям создают объект, к нему прикладывают перечень позиций, и ждут исполнения. Сначала стало получаться, потом снабженцы начали тупо отклонять такие задачи, с комментарием типа «не надо нам ставить отдельные поручения на нашу рутинную работу». В общем, правильный комментарий – если на каждый чих ставить задачу, то и уборщиц придется подключать к системе.
Проблему решили автозадачами и Айсбергом, который там включен по умолчанию. Автозадача просто сморит на дефицитку, разбивает недостающие позиции по исполнителям, и формирует некие объекты, содержащие информацию о том, что надо заказать у поставщиков. Дата формирования автозадачи фиксируется автоматически, равно как и дата исполнения, т.е. размещения позиций у поставщиков.
Если надо было, например, 100 втулок, а снабженец заказал 70, то автозадача не закрывается, а просто корректируется – теперь надо разместить 30 позиций. Что важно – дата начала негативного состояния, т.е. дефицита, остается прежней. 70 позиций человек заказал за один временной интервал, а 30 – за другой.
С применением Айсберга проблема очень быстро решилась, потому что скрыть уже ничего не получалось. Во-первых, учет длительности дефицита ведется в разрезе позиций и количеств, во-вторых – с привязкой к исполнителю. Тут же, разумеется, родился некий KPI для снабженца – какой процент позиций он заказывает в срок (кажется, он должен был в сутки уложиться, с момента возникновения потребности).
Хорошо ложится Айсберг на бухгалтерию. У тех ведь как – постоянно где-то что-то не так. Отрицательные остатки присутствуют, по самым разным счетам, или по ненавидимым ими регистрам. Авансы не зачитываются, несмотря на применение восстановления последовательности расчетов. Не говоря уже о суммовых остатках без количества, и наоборот.
В обычном состоянии системы, без Айсберга, докопаться до бухгалтерии сложно. Единственный способ доказать, что минусы висят уже месяц, это бэкап. Но они тоже не дураки – скажут, что да, месяц назад были минусы, потом мы их убрали, а сейчас опять вылезли, это вы, программисты, чего-то напутали. Если снабженцы просто отмазываются, не перекладывая проблем на других, то бухгалтеры давно придумали – не знаю, осознанно или нет – такой метод, как искусственный цейтнот.
Вот есть на предприятии приличный программист, который заботится о состоянии учета. Видит он минусы в оборотке, и говорит бухгалтерам – милые тётеньки, чего ж вы делаете, давайте устраняйте! Они сначала говорят – да, конечно, устраним, это же в наших интересах. Минусы сильно помешают нам при закрытии квартала, обязательно устраним. В этот момент – допустим, это май – никакого цейтнота, т.е. ограниченного времени на решение задачи – еще ни у кого нет. Поэтому задача наведения порядка, как и положено, откладывается в дальний ящик.
Предотвратить создание отрицательных остатков методами контроля текущей, ежедневной работы, практически невозможно. Даже если запретить списание в минус – есть ведь исправление прихода. Поэтому наш приличный программист вздыхает, и ждет.
До наступления конца июня программист, допустим, еще несколько раз напоминает бухгалтеру, что неплохо бы минусы убрать. Чем ближе срок, тем агрессивнее становится ответ – отвали, не твое дело, не учи нас работать, и, в конце концов, полное игнорирование.
И вот пришел июль, надо закрывать квартал. Теперь задачу надо решать в режиме цейтнота – максимально быстро и эффективно, потому что еще куча дел, кроме минусов. Если вы работали программистов на заводе, то знаете, что происходит в этот момент – задача быстро и красиво перекладывается с бухгалтерии на программистов.
Возмущаться уже поздно, хотя программисты и пытаются. Но бухгалтеры приводят железные аргументы – все, некогда, надо отчетность сдавать, а там таааакиииие штрафы, что компанию закрывать придется. Руководителю, модерирующему ругань программиста и бухгалтера, ничего не остается, как встать на сторону последнего – слишком реально звучит угроза. Программист там что-то ноет, вроде это работа бухгалтера, они отлично знают, что надо делать, и вообще программист обходится компании втрое дороже, чем бухгалтер, и все это неправильно, но уже поздно – искусственный цейтнот создан.
Заканчивается, обычно, так: программист соглашается-таки исправить минусы своими руками, а руководитель и бухгалтер клятвенно обещают заняться этой системной проблемой после устранения цейтнота. И так – каждый раз.
Решение проблемы – аналогичное снабжению. Делаем автозадачу на каждый вариант косяка – например, вычисляем и показываем минусы в оборотке, ставим ответственного и, главное, дату возникновения задачи, чтобы получился Айсберг. Теперь, как только минус возник, появляется автозадача, и ее можно использовать как аргумент в спорах.
Понятно, что бухгалтерия будет игнорировать эти автозадачи. Но зато появится то, чего не хватает программисту на совещаниях с руководством – факты. Вот косяк, вот дата его возникновения, вот длительность негативного состояния – месяц, допустим. Главное правильно подать информацию – смотрите, уважаемый руководитель, наш учет уже месяц находится в неуправляемом состоянии, мы понятия не имеем, сколько стоит наш склад, сколько мы понесли затрат, потому что у нас минусы. Сами понимаете, дорогой руководитель, дело ведь не в минусах, а в отношении к учету. Минус – это крайняя ситуация, очевидная и явная ошибка. А есть еще неявные, которые глазу не видны, но лишают вас возможности пользоваться данными. Ну и так далее.
Еще Айсберг прям просится в любые процессы, где есть согласование. Заявки на расходование денежных средств, договоры, спецификации, бюджеты, планы, выдача спец.одежды и так далее, до бесконечности.
Бюрократы любят согласования, но не как процесс, который надо делать, а как процесс, который можно бесконечно затягивать. Наивный программист, которому поставили задачу добавить в договор согласование главбуха или финансового директора, поступает просто и незатейливо – добавляет в этот самый договор некое поле, типа «Согласовано». Он не знает про Айсберг, поэтому обрекает процесс согласования договоров на медленную и мучительную смерть.
Динамить согласование будут до бесконечности, если договор – какой-нибудь не очень значимый, и не находится в поле зрения директора. А инициаторам договоров ничего не останется, как бегать периодически к главбуху, чтобы узнать, когда произойдет-таки великое таинство.
Айсберг решает проблему сразу и быстро. В данном случае достаточно знать две даты – когда отправлено на согласование, и когда оно состоялось. Длительность состояния несогласованности в этом случае вычисляется элементарно, и можно это время банально нормировать.
Я так делал с согласованием договоров, где цепочка состояла из нескольких людей – руководителя подразделения, финансиста, бухгалтера и юриста. Каждому были отведены сутки на согласование, и Айсберг довел процент попадания в этот срок до 90 %.
Потом, правда, началась проблема с другой стороны – когда договор согласован и подписан на бумаге, оба экземпляра отправляются контрагенту, чтобы он свои подпись и печать поставил. Соответственно, бумажка потом должна вернуться обратно, чтобы попасть в архив юридического отдела.
Но люди, жаловавшиеся ранее на долгое согласование, не спешили сдавать оригиналы договоров юристам. Они вообще об этом забывали – им достаточно того, что договор подписан, и можно с контрагентом работать. Тут взвыли юристы – нельзя без оригиналов, любая проверка устроит компании такой Освенцим, что мало не покажется.
Соответственно, появился еще один Айсберг, для сдачи оригиналов договоров. Отвели месяц для обычных, и 100 дней для ВЭД-договоров. И все, заработало. Особенно, когда юристы стали отклонять новые договоры, пока старые не сданы. Картинка о количестве и сроках несданных договоров была постоянно доступна в системе, и, ввиду важности этого вопроса, была на постоянном контроле руководства. Никому не хочется слишком часто попадать в сферу интересов директора, поэтому сдавали оригиналы почти всегда вовремя.
