КНИГА "CONFIG MANAGEMENT FOR SENIOR MANAGERS"

Почему я решил прочитать эту книгу:

  • во-первых, потому что это задание в курсе “Системный менеджмент и стратегирование”
  • во-вторых, потому что в курсе ailev учит, что в бардаке надо начинать с управления конфигурацией. А я толком даже не понимал, что значат эти два слова
  • и в третьих, потому что я вполне senior manager, которому адресована книга

Стоит ли читать книгу? Определённо стОит, особенно если вы как и я, senior manager, вокруг которого бардак. Но учитывайте, что книга скорее методологическая и кругозорная. Несмотря на наличие практических хинтов, автор честно говорит о её назначении:

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

Если вы впервые услышали про управление конфигурацией, я бы рекомендовал сначала ознакомиться с бытовым примером. Ужасы ремонта знакомы каждому из нас лично, либо через одно рукопожатие. В статье есть недочеты, но суть она передает норм.
А после прочитать пост Анатолия Левенчука с краткой вводной про дисциплину и где-когда нужна. Пересказывать не буду.

О ЧЕМ ВООБЩЕ КНИГА

Мало кто из моих знакомых предпринимателей имеет представления о дисциплине. По дефолту эта практика вшита только в IT-отрасли. А в “традиционных бизнесах” инженеры-проектировщики и инженеры-технологи советских предприятий из 90х давно подвымерли. Молодые бизнесы вообще их не видели. Так и вышло, что явно практики инженерного учёта никто не ставит. Зато уйма информации про учёт финансовый или складской, которые имеют общее с конфигурационным, но всё-таки про другое.

Итак, конфигурация -- это знание “всех кому положено” о том, какова работающая актуальная система, выделенная из множества её возможных вариантов. В каком-то смысле книга про то, как важно сотрудникам быть едино-мышленниками. То есть единообразно представлять те штуки, которые они вместе делают. Когда конфигурационный инженер реализует, например, подпрактику идентификации, он сильно унифицирует это представление.

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

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

Организация - это тоже система, которая имеет архитектуру и описания. Сотрудники имеют какие-то представления о ней. Часто в этих представлениях бардак еще бОльший, чем в представлениях о выпускаемой продукции. Например, недавно мы решили уточнить, сколько “мертвых душ” скопилось среди 1200 аккаунтов в корпоративной 1С. По итогу не менее 400 уже давно не наши сотрудники.. То есть в каком-то описании частей фирмы сохранилась коллизия.

ПРИМЕР ИЗ ЖИЗНИ

Суть наших услуг: клиент заказывает у менеджера установку оборудования на грузовик(и). Оборудование похожее, но в ходе каждого монтажа по месту могут возникнуть “нюансы”. Так уж сложилось, что два одинаковых “КАМАЗа” могут быть совсем не одинаковыми. Монтаж происходит на выезде у клиента. Монтажник берет набор оборудования, делает монтаж, на месте оформляет заказ-наряды, после чего бэк-офис делает закрывающие документы и бьется за погашение дебиторки. Мы столкнулись с проблемой длинного срока закрытия клиента и начали искать причины.

Проблем в процессе много, но по части УпрКонфинг сразу вылезли следующие:

  • бардак в клиентской номеклатуре. С товарами еще более-менее ОК, а по работы нашли до 14 (четырнадцати!) наименований одной и той же работы. Вплоть до “калибровка тахографа” и “калибровка тахографов” и даже “калибровка тахограф”. Часто это вынужденная мера, т.к. тендерные клиенты требуют закрывающих “как в конкурсной документации”. И надо поженить “тебе-учет” и “себе-учёт”
  • бизнесу 8 лет, за это время мы открыли 8 направлений и закрыли из них 3. Внедрение новых штук в работу и новых позиций в учетной системе во многом стихийное. Номенклатуру по закрытым направлениям никто из базы не убирал. А это в силу особенностей тех бизнесов 70% записей в базе
  • с клиентом подписываем одну спецификацию (таблица вида “номенклатура-цена”), но по факту ставим запчасть-аналог или услугу, которой в его спецификации нет. И даже закрываем документами, хотя формально это противоречит договору
  • монтажник при оформлении заказ-наряда в мобильном приложении может выбрать произвольное наименование позиции. Это ведет к расхождению между заказом клиента и закрывающими документами. Стык вопросов про интеграцию данных ЖЦ в разных ИТ-системах и непосредственно управлением конфигурацией.

ВСЁ ДАЖЕ СЛОЖНЕЕ

Но помимо учётных проблем, связанных с конфигурацией описаний, всплыли и вопросы по конфигурации системы. Проекты меняются, и  проектные изменения должны быть точными и понятными. Их должны отслеживать и довести до всех “кому надо”. Бывает, что мы выезжаем делать машину А111АА136, получили от клиента одни вводные. Выясняем на месте, что вводные клиенты дал - или мы собрали -  безалаберно. Состав установленного оборудования приходится корректировать на лету.

То есть меняем конфигурацию системы. Как это согласовать с клиентом и бэк-офисом? Требования к инженеру-монтажнику ИЛИ к рабочему процессу возрастают. Практики управления конфигурации ставить “рядовым” исполнителям, либо встроить в процесс by-design?

Монтажник становится проектировщиком-на-лету. Доверяем, что он предлагает изменения оправданные? Они экономически обоснованы? Или в бэк-офисе надо согласовывать? А после “внутрянки” клиент нашему решению доверяет, или надо и с ним утрясти? Если надо, кто на его стороне готов согласовать и как? Как донести этот «регламент управления конфигурацией» до сотрудников на «той стороне»? Потому что всплыла  лютая проблема. Часто замученные рядовые сотрудники на местах  уклоняются от подписания заказ-нарядов. Хоть с изменениями, хоть без. Без звонка начальству не добиться приемки работ, а это время. Почему? Видно, “на той стороне” тоже плоховато с процессами.

А может быть лучше перенести эти трудности по максимуму всё-таки на подготовительную стадию? Собирать кейсы отклонений по “Камазам”. Придумать, как не фиксировать состав работ по конкретным машинам до монтажа. В итоге получаем два варианта организационной архитектуры, между которыми надо обоснованно выбрать. Сложно... Но это уже тема совсем другого поста.

ХИНТЫ ИЗ КНИГИ

“Ответьте на вопрос: на каких сборных изделиях вы бы проставили серийный номер? Надо отслеживать изменения в каких деталях?” <под деталями лучше понимать “рабочий продукт”> Ответ на этот вопрос определяет, какие рабочие продукты являются вашими конфигурационными единицами. У нас в этом месте началась лютая дискуссия о сложности партионного учёта для разных элементов системы. Всё-таки издержки учёта не должны перевешивать выгоды учёта. Но вопрос тру.

Документы клиенту - только через "одно окно". Чертежи или данные передавать клиенту только через управляющего конфигурацией. Он ведёт учет  таких операций. Если клиент получает документацию производственного процесса, менеджер СМ делает учётную запись.Проблема потери документов о проведённом монтаже регулярная. Но в нашем случае клиенту определенные доки нужны сразу по факту монтажа. Слать “потом” будет сложнее и дороже. Снова на монтажника возлагается кусочек СМ-функции? Зачем учитывать “передачу клиенту чертежей и данных”, стоит ли такая овчинка выделки? Не нашли пока ответы на эти вопросы.

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

И связанная установка: “технические подтверждения на чертежи, спецификации, готовый к выпуску код и отредактированные изменения собирает компетентный инженер”. Вопрос «кто подписывает?» решают по контексту процесса. Однако примите, что многие функции участвуют в процессе, но немногие подписывают документы. Прошедшим курс СМС ясно, что часто согласования по работе компании - “инженерные” по сути. Они про устройство компании, а не по поводу текущей эксплуатации ресурсов. Но квалифицированных “инженеров компании” еще меньше, чем явных инженеров продукта. Отсюда эти трудные согласования корпоративных изменений.

БОНУС ДОЧИТАВШИМ ДО КОНЦА

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

3 лайка

Тоже сейчас по заданию эту книжку читаю. Но у меня домен — космическая промышленность. С институтской парты учили ЕСКД, поэтому у меня когда книжку читаю всегда перед глазами возникает нормоконтроль, отк, извещения об изменинии по ГОСТ 2.503. И вообще понимание появляется зачем это нужно. Потому что есть такое ощущение, что на старых предприятиях Роскосмоса, которые еще советские когда то всё это хорошо понимали, а сейчас остались одни ритуалы. И там люди тратят огромные деньги на внедрение модных PLM-систем, а как потом подружить это с нормативной документацией не знают. Вот и живут параллельно бумажный архив с печатями «контрольный экземпляр» и журнал «учтённых копий».

Это я всё подводил к конкретному вопросу из эссе:
> Зачем учитывать «передачу клиенту чертежей и данных», стоит ли такая овчинка выделки? Не нашли пока ответы на эти вопросы.

Если документы передаются как «архивные» к делу подшить, то кажется, что никаких проблем быть не должно. Но любой чертёж — это описание системы. И если меняется сама система, но не меняется описание — коллизия. И наоборот, описание поменялось, но не поменялась система — тоже коллизия.

Итого — если по тем чертежам, что передали сделаны работы. А потом заказчик что-то решил по месту поменять — у вас коллизия, потом можно будет часами выяснять почему по своим чертежам вы не можете понять как такое быть. И наоборот, в результате каких-то работ поменяете систему, но переданные чертежи не обновите — проблемы у них.

Вот для этого в том же ЕСКД, надо вести учёт кому-что передано, потому что извещения об изменении рассылаются потом по всему списку, кто в этом реестре есть.

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

Ну и не совсем к делу относится, но между конструкторами, вообще, 3D модели ходят, а не чертежи. Чертежи с синими печатями тоже остаются в «тебеучёте»

спасибо, у нас вот система попроще, но теперь я понял, что суть была в “чертежах и данных, которые клиент будет в работе использовать”, а не “для галочки”, как часто передаются доки

вообще, я щас как раз по итогам задания про систему ведения версий понял, что ни черта не понял в вопросе!
надеюсь, что ты это задание сделаешь мышлением-письмом, и твой пример нам всем будет наукой )) я прям даже в очередном посте своем про это пишу запрос во вселенную ))

про 3d-модели тоже годное замечание, я вот не понял в одном из заданий “известно, кто и когда внес изменения”. По идее в цифровых системах уже по дефолту ставится тайм-штамп и автор". Но вот как быть, когда вовсю уже идет NoOps, который например Анатолий уже предлагает и на датаОпс, и на ОргОпс протягивать. В этом случае кого считаем внесшим изменения - робота или того, кто алгоритм действий робота, читай, приказ ему писал? мудрёно.

Юрий, привет! поделись, пожалуйста, переводом! @vladsvyazhin телеграм

Если не сложно, скиньте, пожалуйста, перевод книги на dim-job@bk.ru.
Спасибо заранее!

Если еще актуально, прошу поделиться переводом книжки про менеджмент конфигурации… Спасибо!

Юрий, добрый день! Поделись, пожалуйста, переводом! o.lykov@avego.su

Юрий, добрый день! Поделитесь, пожалуйста, переводом: o.lykov@avego.su

Юрий, здравствуйте! Если можно, поделитесь переводом. Mbf@mail.ru. С уважением, Виктор

Юрий , здравствуйте!
Если , это возможно скиньте перевод sal_rr@mail.ru
Уж как я намучился с конфигурациями изделий в разработке радионавигационных систем.

С уважением, Ринат