Принцип "Айсберг"

Управление - Бизнес-процессы

21
Простой принцип, который стоит учитывать при автоматизации.

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

Аналогичная ситуация – с данными в автоматизированных системах.

Мы, обычно, видим сами данные. Документы, вроде накладных на отгрузку или поступление, перемещения, платежки и т.д. Справочники – номенклатуру, контрагентов, подразделения. Задачи видим, и обычные, и процессные. Остатки видим – сколько лежит товаров на складе, кто нам денег должен, сколько у нас дефицитов и т.д.

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

Мгновенно оценить состояние мы вполне способны – и в автоматизированной системе, и в жизни. Оценили, убежали и забыли.

Потом, через какое-то время, нам на глаза снова попадаются те же данные, или ситуация. Мы снова делаем мгновенную оценку состояния – говорим «все хорошо» или «все плохо». Так повторяется второй, третий, сто двадцать пятый раз.

Если мы оцениваем ситуацию, как критическую, то, наверное, как-то будем ее исправлять. А если нет? Да, ситуация не очень хорошая, но вроде жить можно. Так часто бывает на оперативных совещаниях – кто-то поднимает вопрос, рассказывает ситуацию, дает оценку. Все охают, или цокают языками и… что? Как правило – забывают. До следующего раза, пока снова кто-то не обратит внимание.

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

Почему так происходит? Чего не хватает в информации о негативной ситуации? Мгновенная оценка есть, достаточно качественная и детальная. Как продолжить фразу «вот тут все плохо», чтобы она заиграла новыми красками, и стала более информативной?

Продолжить фразу очень просто: «вот тут все плохо, и уже давно». Время, или длительность состояния – та информация, которая нужна для адекватного принятия решения.

В жизни это всем понятно. Приведу пару примеров.

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

«Нога что-то болит» - ну, мало ли, отсидел может, или погода на артрит влияет. «Нога что-то уже полгода болит» - срочно беги в поликлинику.

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

Аналогично в бизнес-системах.

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

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

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

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

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

Много найдете состояний с измеренной длительностью? Традиционно присутствуют два отчета по принципу «Айсберг»: неликвиды и просроченная задолженность. У вас, кстати, видны неликвиды? Не во всех, даже распространенных системах, неликвиды можно увидеть.

К сожалению, в информационных системах даже понятия «состояние» нет. Присутствуют данные и средства их просмотра, под разными углами. Шикарный простор для аналитика, который любит ковыряться в больших массивах цифр, но мало толковой информации для принятия решений. Причем, не важно, кто решение принимает – человек или сама система.

Способов реализации принципа «Айсберг» несколько. Традиционный – партионный учет, когда в массив информации добавляется разделитель – документ партии. Например, пришел товар на склад – мы запоминаем не только номенклатуру и количество, но и документ прихода – накладную. У накладной есть дата, и по ней мы всегда можем вычислить срок остатка. Аналогично поступают, например, с дебиторской задолженностью – хранят не только контрагента и сумму, но и документ, который эту задолженность создал – например, накладную на отгрузку, или авансовую платежку поставщику.

В техническом плане документ партии создает много трудностей.

Во-первых, он увеличивает количество записей в таблицах. Одна запись «Втулка, 10 штук» может превратиться в десять записей – «Втулка 1 шт от 01.09.2017», «Втулка 1 шт от 09.12.2017» и т.д.

Во-вторых, необходимы алгоритмы списания партий. Например, при отгрузке (т.е. списании товара) нужно знать, с какой партии минусовать остаток. Или при оплате от покупателя нужно указывать, за какой документ отгрузки пришли деньги. Подхода используется два: либо автоматическое вычисление партий, либо ручное их указание. Автоматический выбор партии – это известные стратегии списания FIFO (сначала – самая ранняя партия) и LIFO (сначала – самая поздняя партия). Ручное указание партий обычно используется в разнесении платежей.

Третья проблема, скорее, методическая – реальная жизнь не подчиняется алгоритму списания партий. Кладовщик возьмет с полки деталь, но не ту, которую выбрала программа. Он ведь не знает, что такое FIFO.

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

Второй способ – не хранить длительность всех состояний, а вычислять ее при необходимости. Это мгновенная оценка длительности. Например, так можно найти неликвиды на складе, не храня партии. Способов много – например, понимая текущие остатки, ретроспективно посмотреть на движения товаров. Если движений не было, то перед нами – неликвид.

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

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

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

Третий способ – вычислять, отделять, хранить и отслеживать купированное состояние.

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

Просто сохраняете в отдельном месте системы список просроченных позиций, с количествами и, главное, датой возникновения. Там ведь не всегда есть просроченные позиции? Как только появились – запоминаете, и дата появления будет точкой отсчета длительности.

Дальше система делает все сама. Периодически просматривает дефицитку – проверяет, есть ли просроченные позиции. Если нет – отлично, значит негативное состояние прекратилось. Сохраненный список просроченных позиций можно забыть и удалить из системы (тут на ваше усмотрение, можете оставить на память, т.е. для ретроспективного анализа или системы мотивации). Если же просроченные позиции в дефицитке все еще присутствуют – тоже хорошо (для системы), потому что делать ничего не надо, часики тикают, длительность нарастает.

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

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

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

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

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

Ключевые признаки этого способа: отдельное хранение данных о состоянии и автоматическая их актуализация. Технически реализуется с помощью принципа «Автозадачи», который будет рассмотрен далее.

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

Главное – не забывайте о принципе «Айсберг», когда программируете бизнес-систему.

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

Мгновенную же оценку длительности, как и «Автозадачи», можно включить в любой момент. Ну и выключить тоже. В этой легкости – их преимущество.

 

21

См. также

Комментарии
Сортировка: Древо
1. genayo 16.08.18 10:36 Сейчас в теме
На первый взгляд, проще всего вычисление длительности состояний делать в аналитических системах, типа Кликвью. Дополнительным плюсом будет отсутствие нагрузки на оперативную систему.
2. 1c-intelligence 5176 16.08.18 11:01 Сейчас в теме
(1) мне кажется, вполне можно в 1С сделать. У большинства людей только 1С да сайт есть.
22. Артано 624 20.08.18 06:30 Сейчас в теме
(1)
На первый взгляд, проще всего вычисление длительности состояний делать в аналитических системах, типа Кликвью. Дополнительным плюсом будет отсутствие нагрузки на оперативную систему.


(1) Клик далеко не крупнотиражное решение. Цена покупки и цена владения достаточно высока. Автор же предлагает методологию, позволяющую малой ценой иметь схожий результат на любом предприятии
23. genayo 20.08.18 08:03 Сейчас в теме
(22) Клик бесплатен на одного пользователя, что даёт определённые возможности. Длительность состояний вычислить в 1С иногда бывает слишком затратно без специально заложенных в архитектуре объектов. А методология нормальная, не спорю.
3. Timur.V 21 16.08.18 12:18 Сейчас в теме
Заодно и систему восходящего реагирования можете выстроить. Например, сначала просрочку в дефицитке показывать снабженцу. Через сутки, если не устранил – начальнику снабжения. Через трое суток – коммерческому директору. Через неделю – директору.

Это перекликается с 1С-Документооборотом ))
Там есть эскалация до руководителя, в случает пропуска срока исполнения.
4. 1c-intelligence 5176 16.08.18 12:22 Сейчас в теме
(3) да, есть в ДО такая штука.
5. acanta 44 16.08.18 12:49 Сейчас в теме
В противовес айсбергу есть система "все к лучшему в этом лучшем из миров".
Эти позиции не заказаны снабженцами - значит они не нужны клиентам/сняты с производства/изменились условия закупок.
Вариант - убрать из активного прайс-листа и найти замену.
Напоминания в ДО приведут к тому, что само ДО превратиться в спам и перестанет работать как система взаимодействия.
6. pm74 126 17.08.18 08:12 Сейчас в теме
(0) еще некоторую информацию можно вытянуть из жр ,
автозадачи рулят однозначно ,
еще есть способ "светофоров" - это когда состояние процесса можно однозначно сопоставить документу, исполнителю и состоянию документа (мб регистра или другой сущности ). Это "шифруется" определенным цветом и выводится в журнал/отчет/табло . Многократная и мгновенная визуальная оценка позволяет оценить кто же в процессе постоянно самое слабое звено и , на выбор, исправить сам БП или выписать исполнителю волшебный пендель. Последнее кстати дополнительно стимулирует побыстрее "переключить сфетофор" и ускоряет процесс.
7. 1c-intelligence 5176 17.08.18 08:30 Сейчас в теме
(6)
автозадачи рулят однозначно

вы пользовались автозадачами?
8. pm74 126 17.08.18 08:32 Сейчас в теме
9. genayo 17.08.18 08:44 Сейчас в теме
(8) О, а вот и практическая реализация. Статья однозначно полезна :)
11. 1c-intelligence 5176 17.08.18 08:48 Сейчас в теме
(9) мне показалось, или вы мне первый раз плюсик поставили?
13. genayo 17.08.18 08:50 Сейчас в теме
(11) Не помню, если честно. Я плюсики ставлю, чтобы публикация в избранное попала и проще найти, а ваши статьи итак найти просто.
14. 1c-intelligence 5176 17.08.18 08:55 Сейчас в теме
(13) я не обижусь, если вы будете ставить моим статьям плюсики просто так. В избранном можно создать отдельную папку, чтобы не засорять список статей, которые вы реально хотите быстро найти потом.
Serg O.; Rustig; +2 Ответить
15. genayo 17.08.18 08:58 Сейчас в теме
(14)Хорошо, буду ставить, если для вас это важно.
1c-intelligence; +1 Ответить
17. 1c-intelligence 5176 17.08.18 09:00 Сейчас в теме
(15) не то чтобы важно, скорее - полезно.
Спасибо.
20. Rustig 990 17.08.18 12:31 Сейчас в теме
(14) прикольно, вы хакнули систему лайков
я думал как разделить систему лайков - на "включить в избранное" и "просто лайк"
10. 1c-intelligence 5176 17.08.18 08:47 Сейчас в теме
(8) мне показалось, мы о разных автозадачах говорим. Я - вот об этих.
12. pm74 126 17.08.18 08:50 Сейчас в теме
(10) без разницы
пример " светофоров" на рисунке
Прикрепленные файлы:
16. 1c-intelligence 5176 17.08.18 08:59 Сейчас в теме
(12) такие светофоры - объектные, привязаны к ссылкам - документам, процессам и т.д.
Если нет объекта, то привязывать не к чему. Например, есть процесс "заказ позиций по дефицитной ведомости". Объектов там нет. Одна позиция номенклатуры может требоваться для разных потребителей - заказов покупателей, на производство, в пополнение буфера.

Привязать светофор не к чему. Не к отчету же привязывать?

Автозадача как раз и выступает таким объектом. Она берет кусок реальности, выделяет его, и начинает за ним следить. Например, за просроченными позициями в дефицитке. К автозадаче уже можно и нужно приделать светофор.
18. pm74 126 17.08.18 09:03 Сейчас в теме
(16)
такие светофоры - объектные

я и говорил про объекты
Автозадача как раз и выступает таким объектом

ну да я это и имел в виду

способы можно комбинировать
19. Rustig 990 17.08.18 12:23 Сейчас в теме
Кто-то, конечно, припоминает – о, это ведь уже было, не помню, вроде месяц назад, или может полгода.

есть желания клиентов - которые желательно решить, но платить не хочется,
есть проблемы - которые рекомендуется решить, но на это нет денег,
а есть боли клиентов - которые надо решить, иначе потеряем деньги.
21. acanta 44 17.08.18 16:43 Сейчас в теме
(19) И все это субъективная оценка умноженная на стоимость человеко-часа конкретного субъекта, которую даже нельзя усреднить покером планирования.
Оставьте свое сообщение