Айсберг, кейсы

Сам принцип изложен в статье. Но многие мне писали, что не хватает примеров. Исправляюсь.

Приведу несколько примеров использования Айсберга из своей практики.

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

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

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

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

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

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

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

Есть только информация о том, что нужно заказать. Да, она бывает разного уровня детальности – иногда просто перечень номенклатуры и количеств, иногда – в разрезе получателей, контрагентов, заказов, подразделений и т.д. Но эта информация всегда мгновенная, как вспышка. Зашел – видишь, надо 1020 штук заказать. Через минуту зашел – ого, уже 1200, потому что ситуация изменилась.

Снабженцы это понимают, и пользуются в своих интересах. На совещаниях, разборах и оперативках до закупщиков часто пытаются докопаться, но с них, как с гуся вода. Говорят им – э, ребята, а чего втулок не хватает? Так это вчера только потребность возникла! – отвечают те. Как вчера? Ну так, вчера. Клянусь, вчера утром заходит в дефицитку, там не было втулок!

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

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

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

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

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

Если надо было, например, 100 втулок, а снабженец заказал 70, то автозадача не закрывается, а просто корректируется – теперь надо разместить 30 позиций. Что важно – дата начала негативного состояния, т.е. дефицита, остается прежней. 70 позиций человек заказал за один временной интервал, а 30 – за другой.

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

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

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

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

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

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

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

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

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

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

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

Еще Айсберг прям просится в любые процессы, где есть согласование. Заявки на расходование денежных средств, договоры, спецификации, бюджеты, планы, выдача спец.одежды и так далее, до бесконечности.

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

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

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

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

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

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

Соответственно, появился еще один Айсберг, для сдачи оригиналов договоров. Отвели месяц для обычных, и 100 дней для ВЭД-договоров. И все, заработало. Особенно, когда юристы стали отклонять новые договоры, пока старые не сданы. Картинка о количестве и сроках несданных договоров была постоянно доступна в системе, и, ввиду важности этого вопроса, была на постоянном контроле руководства. Никому не хочется слишком часто попадать в сферу интересов директора, поэтому сдавали оригиналы почти всегда вовремя.