Что-то подзашиваюсь я с нагрузкой — в параллели два проекта: один в стадии разработки, другой в стадии запуска, и переводы начинают задерживаться. И проекты эти связаны с внедрением программного обеспечения. А Эли Шрагенхайм тем временем опубликовал новый материал, в этот раз посвященный животрепещущей теме: программное обеспечение.
Являясь консультантом-методистом, я всегда испытываю огромную потребность в поддержке со стороны программного обеспечения. Настолько, что выступил соавтором и постановщиком задачи для программного продукта по управлению наличием NET Stock. Но программное обеспечение само по себе не способно принести пользы без грамотного его использования — инструмент — он инструмент и есть, и если вы его используете не по назначению, то виноват ли в этом инструмент?
Кто-то может сказать, что Эли опять очень общо высказывается, но общее понимание помогает искать частности. Так что: читайте, комментируйте, высказывайтесь.
Как обычно, ссылка на оригинал и картинка из поста автора.
Ваш Дмитрий Егоров.
Программное обеспечение – это одновременно и благословение и проклятие. Современный рывок в области Больших Данных (Big Data), Индустрии 4.0 и совершенных алгоритмов прогнозирования отражает надежду, что программные продукты расскажут нам о том, чего мы не знаем. Другими словами, сократят угрозы неопределенности и вернут надежду на действительно оптимальное функционирование организации.
Покойный Эли Голдратт посвятил две книги влиянию программного обеспечения. Еще в 1990 году он написал «Синдром Стога Сена», показав потенциальный ущерб от перегруженности океаном данных. Он определил «информацию» как ответ на заданный вопрос, указав таким образом на потенциальную ценность поиска ответа на вопросы. Согласно Голдратту корневой вред программных продуктов – это неспособность за деревьями увидеть лес.
В другой книге «Необходимо, но Недостаточно», написанной в 2000 году вместе с Эли Шрагенхаймом (Eli Schragenheim) и Кэрол Птак (Carol Ptak), Голдратт обращает внимание на мир ERP и необходимость четко определить, как пользователь собирается получать реальную ценность.
Программное обеспечение дает организациям две очевидных выгоды: ведение баз данных и быстрых вычислений. В качестве третьего элемента может быть добавлено управление коммуникациями. Простота, основное открытие ТОС, предполагает, что логика, лежащая в основе вычислений, ясна и согласована пользователями. Голдратт назвал программный продукт, который он разрабатывал в конце 80-х «Катастрофа» (Disaster), чтобы подчеркнуть, что произойдет с пользователем, которых запустит программный продукт без понимания его логики.
Проста против Изощренности – это ключевая дилемма программного продукта. Простота создает ценность, благодаря принятию лучших решений и более эффективных действий. Изощренность же, главным образом, доказывает способности разработчиков программного обеспечения («мы можем это сделать») и обслуживает мечту об оптимальном функционировании в сложной и неопределенной среде. TOC бросает вызов предпосылке, что единственный способ улучшить работу организации – это обеспечить оптимальное функционирование всех ресурсов. TOC утверждает, что концентрация на действительно важном (например, потенциальные потребности пользователей, которые сегодня не удовлетворяются) может дать прорыв, о котором процессы оптимизации даже не знают.
Программное обеспечение может предложить еще одну выгоду, хотя и косвенную:
Программное обеспечение заставляет пользователей исполнять определенные процессы, которые соответствуют ключевым политикам.!
Эта способность программного обеспечения является источником множества специфических дилемм, касающихся различных «за» и «против» каждой политики. Политики и их последствия определяют, является ли программное обеспечение, обеспечивающее ее выполнение, благом или проклятием.
Софтверные компании обычно разрешают эту дилемму, предоставляя пользователю широкий выбор основных параметров политик. С другой стороны, Голдратт стремился минимизировать совершаемые людьми общие крупные ошибки. По его сочному выражению: «Мы не должны давать пользователю веревку, на которой он повесится». Этот страх вел Голдратта к сужению пользовательского выбора политик. Философия ТОС состоит в том, чтобы придерживаться достаточно-хороших политик, которые хорошо справляются с неопределенностью. Это источник всех политик и детальных решений ТОС.
Тем не менее, решения ТОС не покрывают все возможные ситуации и бывают случаи, когда необходимы временные отклонения. Это значит, что пользователю должен быть предоставлен определенный выбор: или позволить рассматривать некоторые отклонения в основных политиках, или позволив пользователю обойти предписания программного обеспечения. Такие действия не должны быть частыми и пользователь должен брать на себя полную ответственность за все последствия.
Вот пример, просто, чтобы проиллюстрировать сказанное. Предположим, что целевой уровень буфера определенного SKU составляет 1000 штук и сейчас в системе только 999 единиц. Создадите ли вы заказ на пополнение для одной единицы товара? Если вы отвечаете «это зависит от…», вы понимаете, что может потребоваться определенное отклонение. Сам Голдратт обозначил более сложное правило по запуску заказов на основе планируемой загрузки, иногда запуская заказы раньше, чем нужно, чтобы поддерживать слабое звено постоянно загруженным, что отклоняется от правила приостановки запуска заказов.
Говоря в общем, мы должны судить о любом программном продукте, опираясь на два очень разных критерия:
- Чистая добавленная ценность, создаваемая программным продуктом, по сравнению с уже существующим. Шесть вопросов по оценки ценности новой технологии – мощный инструмент для этой задачи.
- Потенциальный вред, создаваемый программным продуктом.!
Существует три способа, как программное обеспечение может причинить вред:
Функционирование программного обеспечения.
- Ошибки, которые вводят пользователя в заблуждение или приводят к сбоям системы.
- Поддержка ошибочных процедур или ошибочных алгоритмов.
- Позволяет пользователю принимать неправильные решения вследствие слишком широкого выбора.
- Обратите внимание, каждая конкретная функция, которая не создает ценности, фактически создает ущерб потенциальных ошибок и замешательства.
Метод моделирования и установки программного обеспеченияThe way the software has been modeled and installed.
- Это относится к ERP, CRM и всем большим программным пакетам, где существует множество критически важных параметров и настроек, которые должны быть правильно выполнены в программном продукте при установке. Пакеты TOC для методов Барабан-Буфер-Канат (DBR), Упрощенный Барабан-Буфер-Канат (SDBR) и Критическая цепь (CCPM) также требуют моделирования и установки в программном продукте определенных параметров, например, размеров буфера. Если на этом этапе совершается крупная ошибка – размер ущерба может быть ОГРОМНЫМ!!!
Неправильное использование пользователем программного обеспечения.
- Это самый пугающий источник вреда от программного обеспечения. Программный продукт, его установка и настройка могут быть блестящими, но пользователи, которые считают, что им не нужно понимать логику программного продукта, могут причинить огромный вред.
Пакеты программного обеспечения TOC обычно используются как дополнения, которые связаны с существующими ERP или MRP системами. Наличие интерфейса делает установку критически важной. Программное обеспечение для CCPM также обычно связано с Microsoft Project, но некоторые новые пакеты CCPM являются самостоятельными. Однако, управление проектами иногда требует интеграции с ERP, например, для заказов на закупку или управления бюджетом. Если синхронизация между различными пакетами важно, то нагрузка на интерфейс, критически важную часть установки, особенно высока.
В конце концов, моя основная ответственность – дать пользователю возможность полностью понять логику и возможности любого программного продукта. Ограничение выбора вариантов, которые могут быть полезными, может причинить большой вред. Обход требований программного продукта, если пользователь не до конца понимает логику, еще более опасен.
Это значит, что «чемпионы ТОС»[i] и консультанты должны взять на себя ответственность по обеспечению правильного уровня знаний у клиента, включая способы сохранения этого знания при найме новых сотрудников. Тем не менее, существующие шаблоны Стратегии и Тактики (S&T) не включают необходимые действия, чтобы обеспечить непрерывное обучение.
Когда-нибудь в будущем, я бы хотел увидеть полноценную ERP аналитическую систему, основанную на подходе ТОС. Ключевым должно стать понимание необходимости сочетания данных, основанных на интуиции пользователя с строгим числовым анализом. Я прилагаю усилия такого рода в своей инициативе Поддержки решения методами ТОС (DSTOC) и думаю, что это понимание должно быть распространено на всю индустрию программного обеспечения.
[i] В тексте «TOC champions» — термин, используемы в ТОС сообществе для обозначения лидеров в компании, которые заинтересованы и способствуют внедрению ТОС. – прим. переводчика
