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