Синдром стога сена тос и внедрение erp
Что-то подзашиваюсь я с нагрузкой — в параллели два проекта: один в стадии разработки, другой в стадии запуска, и переводы начинают задерживаться. И проекты эти связаны с внедрением программного обеспечения. А Эли Шрагенхайм тем временем опубликовал новый материал, в этот раз посвященный животрепещущей теме: программное обеспечение.
Являясь консультантом-методистом, я всегда испытываю огромную потребность в поддержке со стороны программного обеспечения. Настолько, что выступил соавтором и постановщиком задачи для программного продукта по управлению наличием 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» — термин, используемы в ТОС сообществе для обозначения лидеров в компании, которые заинтересованы и способствуют внедрению ТОС. – прим. переводчика
Источник
Элия Голдратт “Синдром стога сена”
Выуживание информации из океана данных
Часть первая
Формализация процесса принятия решений
1. Данные, информация и процесс принятия решений – как они соотносятся
Мы все утопаем в океане данных, но при этом, очень редко можем получить необходимую информацию.
Вам это знакомо? И это Вас беспокоит?
Если так, то почему бы нам не обсудить это. Не ради пустого разглагольствования, с рыданиями на коленях друг у друга и получения удовольствия от пересказа страшных историй. Давайте обсудим это более обстоятельно так, как если бы мы верили что “способны изменить мир”. Давайте попытаемся найти практическое решение этой терзающей проблемы, которое действительно сможет помочь.
С чего начать?
Логичным было бы сначала определить, что мы подразумеваем под словами данные и информация. В чем их различие? Вот в чем причина нашего недовольства, не так ли? Есть ли их четкое определение? Может быть, оно есть в словарях или других книгах, но никак не на практике.
Сколько раз вам попадался программный продукт, который продается, как “информационная система”, и которая после первой пробы оказывается “системой хранения данных”?
А что тогда данные?
Адрес потребителя – данные. Цена закупки – данные. Каждая часть дизайна продукции или состояние склада – все это данные. Похоже, что каждая строка символов описывающих что угодно о нашей реальности – все это данные. Если так, то, что же тогда информация?
Похоже, что единственный способ ответить на этот вопрос – опровергнуть только что сказанное. Адрес поставщика – это данные, но, для человека собирающегося писать жалобу его адрес, несомненно, информация. Вы можете называть содержимое склада данными, но если вы пытаетесь ответить на вопрос, можно ли выполнить срочный заказ из этих материалов, тогда это информация. Та же строчка символов, которую мы интерпретировали как данные, в некоторых обстоятельствах может стать информацией. Оказывается, что информация появляется только в глазах смотрящего[1].
Неужели мы запутались? Конечно, нет. Интуитивно мы понимаем, что информация это порция данных, которая влияет на наши действия. Для различных людей, или даже для одного и того же человека в разных случаях, одна строчка может быть информацией или данными.
Поэтому совершенно очевидно, что различие между данными и информацией не определяется содержимым, которым наполнена определенная строка символов. Это зависит от отношения к принимаемому решению. Если мы не знаем наперед, какое решение собираемся принять, не знаем заранее что именно нам понадобится, то любая порция данных может в определенный момент рассматриваться как информация. Нет ничего удивительного в том, что так трудно создавать информационную систему из банка данных.
Можем ли мы в нашем изменчивом мире, даже имея возможность различать, сказать априори, что будет информацией? Вообще, возможно ли разработать такую систему, которую с чистой совестью можно было бы назвать информационной системой? Особенно когда такую систему необходимо использовать не для одного типа решений или только одной функции управления.
Ведь нам хотелось бы иметь такую систему, которая снабжала бы информацией всех менеджеров компании для всех принимаемых ими решений. А коль так, то в любой момент времени большая часть такой информационной системы будет всего лишь данными. Ну и что? Если мы получаем информацию, неужели это имеет значение.
Это объяснение приводит нас к старой, существующей системе. Вы видите, что следующим отрезвляющим шагом будет начать спрашивать себя, с какими задачами мы можем столкнуться в будущем. Не только мы, но каждая функция компании. Итак, мы совершили удачный прыжок к следующему этапу – попытка определить часть данных/информации которые могут потребоваться. Отсюда один шаг, чтобы потратить все свои силы на определение подходящих форматов данных, процедур запроса и т. п. … Сейчас это уже нахоженная тропа. Те же методы, только акцент на формате выходных данных. Эти многотомные отчеты пытаются дать ответы на все возможные вопросы. Конечно, в последние годы возможности персональных компьютеров и on-line запросов несколько расширилась, что устраняет данное явление, но, не учитывая, как это делается.
В Израиле есть одна байка, истинность которой я не могу проверить, но не очень удивился бы, если бы такое случилось на самом деле. 10 лет назад одним из путей извлечения информации из компьютера были печатные отчеты. Тогда центральный вычислительный центр израильских вооруженных сил рассматривал новую технологию лазерной печати, как панацею для решения всех проблем. Капитан этого отдела, вероятно очень недалекий, решил справиться с нашей задачей весьма оригинальным способом. Безо всяких объяснений он издал инструкцию убирать из очереди печати все отчеты, содержащие более 100 страниц. В то время, когда компьютерная децентрализация существовала только в мире идей, множество копий отчетов рассылалось из центрального отдела в несчетное количество армейских подразделений. Эпилог легенды говорит, что была всего лишь одна жалоба на это решение. Человек, который прислал ее, занимался подшивкой отчетов в архивные папки.
Каждый менеджер большой организации может иметь отношение к этой легенде. И даже если эта история лишь байка, она недалека от реальности. Что было нашей изначальной жалобой? Мы тонем в океане данных. Ситуация сегодня настолько удручающа, что на всех публичных выступлениях, где я предлагаю связывать принтеры напрямую с редакторами, следует смех и улыбки. Наверно где-то в рассуждении мы приняли неверное заключение. Где-то должна быть логическая нестыковка. Информационные системы не могут исключать необходимости банков данных, но, несомненно, информационные системы это совершенно другие сущности. Если они должны быть эффективными, они просто не могут идентифицироваться с существующими банками данных.
Давайте вернемся к моменту, где мы пытались разграничить понятия данных и информации. Мы пытались определить информацию как данные, которые необходимы для принятия решения. Само это определение не дает нового понимания, но не смотря на это, уже интуитивно понятно, что информация может определяться только в контексте принятия решения. Может информация определяется не как “данные, требуемые для ответа на вопрос”, а как сам “ответ на заданный вопрос”?
Здесь не только семантическое отличие. Прислушайтесь минуту-две к этому и вы, наверное, почувствуете как непросто то, чем я занимаюсь. Вы увидите, что информация это не входные данные процесса принятия решения, а на самом деле выходные. Принятие такого определения подразумевает, что процесс принятия решения должен быть встроен в информационную систему. Это потребует титанических усилий в достижении очень четкой формализации всех процессов управления. В нашем случае это означает открыть еще один ящик Пандоры – ведь в промышленности процессы постоянно изменяются.
Восьмидесятые характеризовались многими профессионалами в области управления, как десятилетие второй индустриальной революции. Революции, которая затрагивает ядро управления нашим бизнесом. Которая ломает общепринятые методологии, на основании которых раньше принимались решения. Каждая конструктивная дискуссия о принципах построения и структуре информационных систем должна происходить в контексте процесса принятия решений. Именно поэтому мы не сможем избежать необходимости анализа новых течений менеджмента.
На первый взгляд это может показаться совершенно другой темой. Мы ведь собирались обсудить информационные системы, и вдруг должны тратить значительное время для анализа философии управления? Но от этого не уйти, если мы хотим исследовать возможность найти работающий метод, который приведет к созданию эффективной информационной системы. Кроме того, может быть простота, которая характеризует новые течения, приведет еще к новому, более простому и более исчерпывающему решению.
2. Чего пытается достичь компания?
“Качество ґ- в первую очередь”. “Производственные запасы – замороженные деньги”. “Сбалансированный поток вместо полной загрузки[2]”. Это всего лишь некоторые из девизов, которые скандируются организациями индустриального менеджмента. В восьмидесятых годах мы стали свидетелями трех могучих течений менеджмента – Всеобщее управление на основе качества (TQM), Точно вовремя (JIT) и Теории ограничений (TOC)[3], которые бросили вызов почти всему, что раньше принималось за аксиому. Все эти течения скромно начинали как локальные технологии. Сейчас все они распространяются со скоростью звука.
Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.
Источник
Элия Голдратт ‘Синдром стога сена’
Выуживание информации из океана данных
Часть первая
Формализация процесса принятия решений
1. Данные, информация и процесс принятия решений – как они соотносятся
Мы все утопаем в океане данных, но при этом, очень редко можем получить необходимую информацию.
Вам это знакомо? И это Вас беспокоит?
Если так, то почему бы нам не обсудить это. Не ради пустого разглагольствования, с рыданиями на коленях друг у друга и получения удовольствия от пересказа страшных историй. Давайте обсудим это более обстоятельно так, как если бы мы верили что ‘способны изменить мир’. Давайте попытаемся найти практическое решение этой терзающей проблемы, которое действительно сможет помочь.
С чего начать?
Логичным было бы сначала определить, что мы подразумеваем под словами данные и информация. В чем их различие? Вот в чем причина нашего недовольства, не так ли? Есть ли их четкое определение? Может быть, оно есть в словарях или других книгах, но никак не на практике.
Сколько раз вам попадался программный продукт, который продается, как ‘информационная система’, и которая после первой пробы оказывается ‘системой хранения данных’?
А что тогда данные?
Адрес потребителя – данные. Цена закупки – данные. Каждая часть дизайна продукции или состояние склада – все это данные. Похоже, что каждая строка символов описывающих что угодно о нашей реальности – все это данные. Если так, то, что же тогда информация?
Похоже, что единственный способ ответить на этот вопрос – опровергнуть только что сказанное. Адрес поставщика – это данные, но, для человека собирающегося писать жалобу его адрес, несомненно, информация. Вы можете называть содержимое склада данными, но если вы пытаетесь ответить на вопрос, можно ли выполнить срочный заказ из этих материалов, тогда это информация. Та же строчка символов, которую мы интерпретировали как данные, в некоторых обстоятельствах может стать информацией. Оказывается, что информация появляется только в глазах смотрящего[1].
Неужели мы запутались? Конечно, нет. Интуитивно мы понимаем, что информация это порция данных, которая влияет на наши действия. Для различных людей, или даже для одного и того же человека в разных случаях, одна строчка может быть информацией или данными.
Поэтому совершенно очевидно, что различие между данными и информацией не определяется содержимым, которым наполнена определенная строка символов. Это зависит от отношения к принимаемому решению. Если мы не знаем наперед, какое решение собираемся принять, не знаем заранее что именно нам понадобится, то любая порция данных может в определенный момент рассматриваться как информация. Нет ничего удивительного в том, что так трудно создавать информационную систему из банка данных.
Можем ли мы в нашем изменчивом мире, даже имея возможность различать, сказать априори, что будет информацией? Вообще, возможно ли разработать такую систему, которую с чистой совестью можно было бы назвать информационной системой? Особенно когда такую систему необходимо использовать не для одного типа решений или только одной функции управления.
Ведь нам хотелось бы иметь такую систему, которая снабжала бы информацией всех менеджеров компании для всех принимаемых ими решений. А коль так, то в любой момент времени большая часть такой информационной системы будет всего лишь данными. Ну и что? Если мы получаем информацию, неужели это имеет значение.
Это объяснение приводит нас к старой, существующей системе. Вы видите, что следующим отрезвляющим шагом будет начать спрашивать себя, с какими задачами мы можем столкнуться в будущем. Не только мы, но каждая функция компании. Итак, мы совершили удачный прыжок к следующему этапу – попытка определить часть данных/информации которые могут потребоваться. Отсюда один шаг, чтобы потратить все свои силы на определение подходящих форматов данных, процедур запроса и т. п. … Сейчас это уже нахоженная тропа. Те же методы, только акцент на формате выходных данных. Эти многотомные отчеты пытаются дать ответы на все возможные вопросы. Конечно, в последние годы возможности персональных компьютеров и on-line запросов несколько расширилась, что устраняет данное явление, но, не учитывая, как это делается.
В Израиле есть одна байка, истинность которой я не могу проверить, но не очень удивился бы, если бы такое случилось на самом деле. 10 лет назад одним из путей извлечения информации из компьютера были печатные отчеты. Тогда центральный вычислительный центр израильских вооруженных сил рассматривал новую технологию лазерной печати, как панацею для решения всех проблем. Капитан этого отдела, вероятно очень недалекий, решил справиться с нашей задачей весьма оригинальным способом. Безо всяких объяснений он издал инструкцию убирать из очереди печати все отчеты, содержащие более 100 страниц. В то время, когда компьютерная децентрализация существовала только в мире идей, множество копий отчетов рассылалось из центрального отдела в несчетное количество армейских подразделений. Эпилог легенды говорит, что была всего лишь одна жалоба на это решение. Человек, который прислал ее, занимался подшивкой отчетов в архивные папки.
Каждый менеджер большой организации может иметь отношение к этой легенде. И даже если эта история лишь байка, она недалека от реальности. Что было нашей изначальной жалобой? Мы тонем в океане данных. Ситуация сегодня настолько удручающа, что на всех публичных выступлениях, где я предлагаю связывать принтеры напрямую с редакторами, следует смех и улыбки. Наверно где-то в рассуждении мы приняли неверное заключение. Где-то должна быть логическая нестыковка. Информационные системы не могут исключать необходимости банков данных, но, несомненно, информационные системы это совершенно другие сущности. Если они должны быть эффективными, они просто не могут идентифицироваться с существующими банками данных.
Давайте вернемся к моменту, где мы пытались разграничить понятия данных и информации. Мы пытались определить информацию как данные, которые необходимы для принятия решения. Само это определение не дает нового понимания, но не смотря на это, уже интуитивно понятно, что информация может определяться только в контексте принятия решения. Может информация определяется не как ‘данные, требуемые для ответа на вопрос’, а как сам ‘ответ на заданный вопрос’?
Здесь не только семантическое отличие. Прислушайтесь минуту-две к этому и вы, наверное, почувствуете как непросто то, чем я занимаюсь. Вы увидите, что информация это не входные данные процесса принятия решения, а на самом деле выходные. Принятие такого определения подразумевает, что процесс принятия решения должен быть встроен в информационную систему. Это потребует титанических усилий в достижении очень четкой формализации всех процессов управления. В нашем случае это означает открыть еще один ящик Пандоры – ведь в промышленности процессы постоянно изменяются.
Восьмидесятые характеризовались многими профессионалами в области управления, как десятилетие второй индустриальной революции. Революции, которая затрагивает ядро управления нашим бизнесом. Которая ломает общепринятые методологии, на основании которых раньше принимались решения. Каждая конструктивная дискуссия о принципах построения и структуре информационных систем
Источник