Проблема – это негативное состояние или событие, которое нам (лично, отделу или компании в целом) чем-либо мешает и угрожает возникновением ещё больших проблем. Значительная часть времени в управлении тратится на "латание корпоративных дыр" или создания таких условий, чтобы проблем не возникало. В этом материале расскажу о способе, который поможет выполнять эту работу системнее и эффективнее.
Существует два типа проблем:
Существующая (возникла здесь и сейчас);
Потенциальная (может возникнуть в будущем).
Проблемы могут быть важными для одних людей, и неважными для других. Так происходит, потому что негативные последствия видит или испытывает конкретный человек или локальная группа лиц, но не весь коллектив. Если социальный вес индивида или группы лиц низкий, то проблема будет считаться для противоположной стороны неважной. Поэтому, зачастую, сложно доносить о наличии проблем коллективу со стороны собственника бизнеса, или, наоборот, со стороны коллектива собственнику.
Отсюда вытекает важный вывод: проблема тем важнее, чем большего числа людей с высоким социальным весом она касается или может коснуться в будущем. Если два человека осознают проблему, то это уже более важная проблема, чем проблема одного человека, но менее важная, чем отсутствие проблем у трёх человек.
Формулировать проблему нужно так, чтобы окружение понимало, что последствия могут коснуться и их.
Я предлагаю ранжировать проблемы таким образом:
Проблемы 1 уровня – те, которые наносят или могут нанести вред всей группе взаимодействующих людей. Такие проблемы можно назвать "Проблемами компании".
Проблемы 2 уровня – те, которые наносят или могут нанести вред группе людей в отделе. Их можно назвать "Проблемами отделов".
Проблемы 3 уровня – те, которые наносят или могут нанести вред конкретному человеку. Это "Проблемы сотрудника"
Локальные проблемы сотрудников (3 уровень) могут сказываться на деятельности отделов (2 уровень). Проблемы отделов сказываются на деятельности компании и возникают системные проблемы (1 уровень).
![Графическое отображение уровней проблем Графическое отображение уровней проблем](https://habrastorage.org/getpro/habr/upload_files/182/abb/725/182abb725f5152d04dc7354ae1c0a2a1.jpeg)
Причинно-следственные связи
Все проблемы компании подчинены закону причинно-следственных связей. Если мы что-то делаем, то что-то происходит. Проблема – это следствие, причиной которого было какое-то действие.
Способ решения проблемы – контрдействия против причин.
Чтобы исправить корпоративные проблемы (следствия), нужно:
Сформулировать проблемы;
Определить, почему это является проблемой.
Определить ранг проблемы (личная, отдела или компании);
Сформулировать причины возникновения проблем;
Скорректировать причины, то есть оказать контрдействие;
Проверить, решили ли мы проблему и закрепить результат;
При отсутствии решения проблемы пересмотреть действия.
1. Формулировать проблемы.
Делать это нужно лаконично. Например: "У нас нет инженера" или "Клиенты отказываются от сотрудничества", или "В отделе нет канцелярии". Для фиксации проблем можно завести раздел в корпоративной базе знаний или предлагать сотрудникам их отправлять на емейл.
2. Пояснить, почему вы считаете, что это является проблемой.
Например: "У нас нет инженера – это проблема, потому что без него мы не можем просчитывать нагрузки сооружений на стены и ошибаемся при проектировании".
3. Определить ранг или уровень проблемы.
Озвученная проблема личная, отдела или компании? Можно отталкиваться от пояснений, в которых уже содержатся подсказки. В приведенном выше примере, по результатам пояснения, выяснится, что "Отсутствие инженера" – это или чья-то личная проблема или проблема отдела (то есть проблема 2 или 3 уровня), а вот "Не можем просчитывать нагрузки" и "часто ошибаемся" – одна из проблем компании (1 уровня). Определение ранга важно с точки зрения расстановки приоритетов и распределения ресурсов. Если проблема напрямую и сильно влияет на экономические результаты компании (в ней есть признаки 1 уровня) – ей стоит уделить большее внимание.
4. Сформулировать причины возникновения проблем.
Для определения причин возникновения проблем существует графический инструмент под названием диаграмма причинно-следственных связей (Диаграмма Исикавы), которая была разработан в середине 20-века для выявления производственных проблем на предприятиях Японии, после чего снискал признание у менеджеров во всем мире.
Подробнее об инструменте можно почитать в Википедии или в сети интернет.
![Если среди читателей есть любознательные математики, то можете обратить внимание, что структура диаграммы напоминает ориентированный граф. Если среди читателей есть любознательные математики, то можете обратить внимание, что структура диаграммы напоминает ориентированный граф.](https://habrastorage.org/getpro/habr/upload_files/880/552/023/8805520231055af5949f3b43cdff0c3f.jpeg)
Как пользоваться инструментом. Если кратко:
Берём лист бумаги и ручку.
Формулируем проблему. Она всегда рисуется на листе отдельным блоком справа.
У проблемы всегда есть следствие. Изображаем его в виде стрелы, упирающейся в проблему слева.
Если проблема локальная, то есть только одна стрела следствий и одна причина.
Если проблема системная, то к основной причине присоединяются с боков в виде стрелок причины 2 уровня, а к ним могут присоединиться причины 3 уровня и так далее. Таким образом получаются дерево причинно-следственных связей.
![Результат составления диаграммы может выглядеть так (взято из сети интернет). Результат составления диаграммы может выглядеть так (взято из сети интернет).](https://habrastorage.org/getpro/habr/upload_files/900/4e8/4ae/9004e84ae90d543bb65b663c361343c2.png)
5. Скорректировать причины, то есть оказать контрдействие.
Приведу пример контрдействий на локальном уровне. Например, мы испытываем голод. В таком случае, диаграмма может выглядеть так:
![](https://habrastorage.org/getpro/habr/upload_files/4b3/4a5/6b6/4b34a56b6417533d47c187c2c6625934.png)
Что нужно сделать, чтобы избавиться от проблемы? Поесть. Мы просто меняем нашу причину со знаком "-" (отсутствие еды в организме) на действие со знаком "+". Таким образом, мы и решаем проблему.
У причины 1 уровня "Отсутствие еды в организме" можно выявить причины 2 уровня. Например, мы не можем поесть, потому что: а)Заняты; б)У нас пустой холодильник. В таком случае, способом решения проблемы будет: а)Высвободить время для еды; б)Сходить в магазин и купить продуктов. в)Поесть.
Такой же принцип "корректировки причин" или контрдействий используется и для решения корпоративных проблем.
6. Проверить, решили ли мы проблему.
Локальные проблемы решаются быстро, но даже насыщение после приёма еды не наступает моментально. Чем масштабнее проблема, тем дольше нужно времени на то, чтобы проявился результат. Соответственно:
После определения проблемы и корректировки действий нужно время;
В зависимости от проблемы (локальная или системная) время изменений может быть разным.
Условный пример для пояснения логики:
Для решения системных проблем на уровне планеты нужны века;
Для решения системных проблем на уровне государства нужны десятилетия;
Для решения системных проблем на уровне компании нужно несколько лет;
Для решения системной проблемы отдела нужен 1 год;
Для решения локальной проблемы сотрудника нужен 1 месяц.
Если вы дождались и увидели изменения после применения контрдействий – закрепляйте поведение. Полезно создать базу ситуационных регламентов, в которую сотрудники отчуждают личный опыт решения проблем на благо компании. Это помогает, с одной стороны, распространять практику на смежные отделы, с другой стороны сокращает время на принятие решений в будущем в похожих условиях.
7. При отсутствии решения проблемы пересмотреть действия.
Я выделаю две причины, по которым проблема может не решиться:
Вы неверно определили причины;
Вы неверно расставили приоритеты действий.
Честно говоря, по последнему пункту у меня нет четкого, 100% работающего алгоритма действий. Если бы человек был способен с максимальной точностью определять все причины тех или иных событий, то мы не сталкивались с понятием "Черных лебедей", да и вся наша жизнь была бы 100% упорядоченной и предсказуемой. Определенно, могу сказать лишь то, что в декомпозиции причинно-следственных связей мы используем дедукцию и абдукцию. Дедукция – логический способ выведения причинно-следственных связей, а абдукция – интуитивный, основанный на любознательности и креативных способностях. Очевидно, стоит эти навыки развивать. Для этих целей можно использовать идеи Элияху Голдратта или ТРИЗ Генриха Альтшуллера.
Что же касается приоритета действий, то здесь можно опираться на метод критического пути (Critical path method), точнее на упрошенную, мою субъективную интерпретацию.
Звучит она так: Чтобы с вероятностью в 100% решить проблему, нужно выполнить все возможные и известные контрдействия. Часть действий будут менее значительными, часть более, но совокупно они неизбежно приведут к результату.
Так как наша задача связана еще и с тем, чтобы проблему решить как можно быстрее – нужно, в первую очередь, найти наиболее короткий путь, в которых присутствует наименьшее количество операций, но с более эффективным, по нашим гипотезам, воздействием.
![Иллюстрация определения критического пути в цепочки возможных контрдействий. Иллюстрация определения критического пути в цепочки возможных контрдействий.](https://habrastorage.org/getpro/habr/upload_files/936/1f7/c52/9361f7c52ffebc251c069d5f01d083d3.jpeg)
Таким образом, если речь идет о решении системной корпоративной проблемы или проблемы в отделе, мы можем сформировать план возможных изменений (варианты путей от множества причин к желаемому следствию) и расставить задачи в порядке, от более простых и мощных к более сложным. Это и будет наиболее оптимальная приоритизация способов решения корпоративных проблем.
Комментарии (4)
SirFox
29.01.2022 01:01При всем уважении к автору, к сожалению, статья получилась ни о чем.
Компиляция теории из википедии, учебников по методам разработки Упарвленческих Решений, рассуждений автора и прописных истин.
Метод критического пути заодно приплели....
Было бы интересно почитать про практику использования инструмента "Диаграмма Рыбий скелет" в ИТ отрасли (в вашей конкретной компании в частности) , а также особо о границах его применимости т.е. для решения каких задач он НЕ подходит.
Также было бы интересно как применяли данный инструмент для анализа рисков, оптимизации бизнес-процессов, улучшения операционной эффективности на разных стадиях ИТ-Проекта.
-
Для создания полноценной статьи, несущей добавленную стоимость ее потребителям,
Попробуйте ответить на вопрос - какую прикладную пользу получит читатель, ознакомившись с данной статьей ? Как можно применить на практике приведенные выкладки. Каким способом можно перенести опыт автора на другие сферы деятельности.
Kirill_Kazakov Автор
29.01.2022 01:16Вы знаете, это хороший опыт – писать статьи (я начинающий автор), получать обратную связь, принимать во внимание замечания для того, чтобы в следующий раз быть полезнее. Поэтому, спасибо за мнение. Подумаю над тем, как делать материалы более практичными.
Прикладная польза статьи в представлении инструмента для тех, кто о нем не слышал или для тех, кто его никогда не использовал. С моей точки зрения, это один из тех рекурсивных (применимых на разных уровнях деятельности), наглядных, математически точных (фактически это вероятностный граф) инструментов, которые очень легки в использовании для анализа причинно-следственных связей. Ну и логика "меняем действия со знака "-" на знак "+" тоже очень понятная. Это помогает уйти от субъективны х представлений "что нужно сделать" к более объективным.
Я ниже прикреплю несколько примеров диаграмм, построенных не мной, но моими студентами в ВШЭ. (Это практические кейсы, реальный бизнес). Сам я тоже использую этот инструмент, конечно. Не в ежедневной практике, но когда речь идет о каким-то системных изменениях – обязательно.
p.s. "Метод критического пути заодно приплели" – выше в комментарии развернул мысль про метод критического пути и его отношение к диаграмме.
Myclass
Не знаю. Искал ключивые слова в вашей статье — не нашел. Ваша «Иллюстрация определения критического пути в цепочки возможных контрдействий» только от того, что вы линии по диоганали нарисовали ещё не значит, что это диаграмма Исикавы. То, что вы попытались иллюстрировать — есть типичная BPMN диаграмма. Конечно — немного упрощённая, но всё-же. И критичные пути определяются не просто визуально, а при помощи данных, которые потом анализируются в Process Mining(е) например с такими инструментами как например вот этот
Kirill_Kazakov Автор
Спасибо за комментарий. Думаю, что мне стоило чуть подробнее осветить причину, по которой я предложил использовать метод критического пути как способа приоритизации контрдействий. Прикрепляю иллюстрацию, которая, на мой взгляд, довольно наглядно реконструирует диаграмму Исикавы с точки зрения сетевой диаграммы, которую я и разместил в конце статьи. Конечно же, вы правы, чтобы быть максимально объективными, нужно все действия разбить на подзадачи, каждую оценить с точки зрения временных и других ресурсных затрат и далее с помощью, например, алгоритма Флойда — Уоршелла осуществить просчет. Но я лишь обозначил верхнеуровневый принцип. Люди могут навскидку прикинуть ресурсные затраты при выполнении действий и так же могут прикинуть влияние (мощность) действий. И исходя из этого уже принять решение.