PROCESS

Вот Как Строить

Проектирование

Пример

Прежде чем начнутся главы, вот случай, к которому они будут возвращаться. Один процесс, увиденный однажды целиком, а затем повёрнутый, глава за главой, чтобы каждое то, из чего состоит правило, можно было увидеть в чём-то настоящем. Читайте сначала как историю. Уроки придут потом.

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

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

Когда приходит проблема, первая настоящая работа не в том, чтобы её решить. А в том, чтобы её рассортировать. Это проблема одного клиента или многих? Если одного, её ведут как отдельный случай, прорабатывая с клиентом или администратором до решения. Если та же проблема начинает появляться у многих клиентов, и Поддержка или система замечает закономерность, её ведут как нечто большее. Признанный отраслевой подход назвал бы большее проблемой. Эта книга называет это возникающей проблемой. Слова значат меньше, чем мышление, а мышление одно и то же в любой отрасли и на любом месте.

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

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

Через всё это проходят шаблоны, и они — сердце этого примера. Есть шаблоны для клиента и шаблоны для Команд внутри. Они несут пути эскалации и стандартные слова для каждого вида проблемы. Они существуют для того, чтобы хорошее сообщение не приходилось изобретать заново, в тревоге, посреди кризиса, тем, кто случайно оказался рядом. Хорошее сообщение встроено в них заранее: написанное на собственном языке получателя и на его собственном уровне, техническое для технического, простое для простого; достаточно полное, чтобы удовлетворить, но не настолько нагруженное деталями, чтобы тревожить читателя без причины; несущее ту этикетность и ту малую политическую осторожность, что позволяют сообщению хорошо лечь там, где оно ложится; и всегда, всегда, заканчивающееся следующим шагом, даже когда следующий шаг — просто подождать.

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

Вот этот случай. Компания, производящая программное обеспечение, отвечает на проблемы: сортирует их, прорабатывает и, прежде всего, сообщает о них, внутрь и наружу, через структуру шаблонов и правил, которая превращает хаос в нечто, чему клиент может доверять, а неизвестное — в известное. Главы, что следуют, берут этот единственный процесс и поворачивают его, чтобы каждую грань правила, что делается, как, когда, почему и кем, можно было увидеть за работой в нём.

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

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

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

Это не книга о том, что должно работать. Это книга о том, что работает стабильно, когда процессы спроектированы для масштабирования, системы согласованы для их поддержки, а организации готовы к трансформации.

ВАЖНОЕ ПРИМЕЧАНИЕ: 

Читателям настоятельно рекомендуется обращаться к оригинальному контенту и делиться им через marvinpro.com. MarvinPro представляет собой постоянно развивающийся свод материалов, содержание которого регулярно обновляется, отражая новые идеи, усовершенствованные подходы и расширенные обучающие материалы. Материалы, скопированные или воспроизведённые в других местах, могут уже не соответствовать актуальной версии, тогда как действующий сайт всегда предоставляет наиболее полную и актуальную образовательную информацию.

© COPYRIGHT 1990-2026 MarvinPro

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

Думай Просто.