Теория ограничений и программное обеспечение: в поисках ценности

Теория ограничений и программное обеспечение: в поисках ценности

Источник

Программное обеспечение (ПО) – и благословение, и проклятие. Сегодня движение к Большим данным, Индустрии 4.0 (Четвертой промышленной революции) и совершенным алгоритмам прогнозирования выражает нашу веру, что ПО расскажет нам то, что мы не знаем. Другими словами, уменьшит угрозу неопределенности и вернет надежду на действительно оптимальную работу организаций.

Покойный Эли Голдратт посвятил две свои книги влиянию программного обеспечения. Еще в 1990 году он написал «Синдром стога сена», в котором показал потенциальный ущерб от нашей перегрузки океаном данных. Он определил «информацию» как ответ на поставленный вопрос, чем указал на потенциальную ценность поиска ответов. Согласно Голдратту, основной вред от современного программного обеспечения заключается в том, что оно не позволяет видеть лес за деревьями.

Другая книга Голдратта «Необходимо, но недостаточно» (в соавторстве с Эли Шрагенхаймом и Кэрол Птак), написанная в 2000 году, обращается к миру ERP. В ней он подчеркивает необходимость четко определить, как пользователь сможет получить от ERP реальную ценность.

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

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

Программное обеспечение может предложить еще одно важное преимущество, хотя и косвенное:

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

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

Софтверные компании обычно решают эту дилемму, предоставляя пользователю широкий выбор настроек для ключевых параметров политик. Голдратт, с другой стороны, стремился свести к минимуму основные серьезные ошибки, которые допускают люди. По его меткому выражению: «Если не дать пользователю веревку, он не сможет повеситься!». Это опасение заставило Голдратта сузить для пользователя выбор политик. Философия ТОС предлагает придерживаться достаточно хорошей политики, справляющейся с неопределенностью. Это основа всех политик и подробных решений ТОС.

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

Чтобы проиллюстрировать это, приведу пример. Предположим, что целевой уровень некоторого SKU 1000 единиц, и сейчас в системе имеется только 999 единиц. Нужно ли оформить заказ на пополнение 1 единицы? Если вы отвечаете, что «это зависит от…», значит, может потребоваться некое отклонение. Сам Голдратт предложил более сложное правило запуска заказов на основе плановой загрузки: иногда запускать заказ раньше, чтобы сохранить самое слабое звено постоянно загруженным, что является отклонением от правила приостановить запуск заказов.

Еще рекомендуем:  Ошибочность учета затрат. Часть 1

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

  1. Дополнительная ценность, которую создает ПО. Шесть вопросов для оценки новой технологии являются мощным инструментом и для определения ценности ПО.
  2. Потенциальный ущерб от использования ПО.

ПО может причинить вред тремя различными способами:

1. Особенности работы программного обеспечения

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

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

2. Особенности моделирования и настройки ПО

Это относится к ERP, CRM и всем крупным программным пакетам, в которые при установке и настройке необходимо задать множество важных решений и параметров. ПО для решений TOC Барабан-буфер-канат и CCPM также требует моделирования и задания определенных параметров, например, размеров буфера. Если на этом этапе допустить серьезные ошибки, ущерб может быть огромным!

3. Неправильное использование ПО пользователем

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

Программные пакеты TOC обычно используются в качестве дополнительных модулей, связанных с существующей ERP или MRP с помощью некоторого интерфейса. Эта связь делает установку пакетов критически важной. Программное обеспечение для реализации Критической цепи может быть связано с Microsoft Project, но некоторые более новые пакеты являются автономными. Однако управление проектами иногда требует связи с ERP, например, для отслеживания заказов или управления бюджетом. Если необходима синхронизация между различными пакетами, интерфейсу отводится очень важная роль.

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

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

В будущем я хотел бы увидеть полный программный пакет ERP + бизнес-аналитика, основанный на подходе ТОС. Его ключевой особенностью должно быть объединение данных, основанных на интуиции пользователей, со строгим математическим анализом. Я думаю, что это понимание должно распространиться по всей индустрии программного обеспечения.

Эли Шрагенхайм
Eli Schragenheim,
CEO of Elyakim Management Systems (1992) Ltd

А что вы думаете?

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.