Синдром стога сена тос и внедрение erp

1. Данные, информация и процесс принятия решений — как они соотносятся

Мы все утопаем в океане данных, но при этом, очень редко можем получить необходимую информацию.

Вам это знакомо? И это Вас беспокоит?

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

С чего начать?

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

Сколько раз вам попадался программный продукт, который продается, как «информационная система», и которая после первой пробы оказывается «системой хранения данных»?

А что тогда данные?

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

Похоже, что единственный способ ответить на этот вопрос — опровергнуть только что сказанное. Адрес поставщика — это данные, но, для человека собирающегося писать жалобу его адрес, несомненно, информация. Вы можете называть содержимое склада данными, но если вы пытаетесь ответить на вопрос, можно ли выполнить срочный заказ из этих материалов, тогда это информация. Та же строчка символов, которую мы интерпретировали как данные, в некоторых обстоятельствах может стать информацией. Оказывается, что информация появляется только в глазах смотрящего[1].

Неужели мы запутались? Конечно, нет. Интуитивно мы понимаем, что информация это порция данных, которая влияет на наши действия. Для различных людей, или даже для одного и того же человека в разных случаях, одна строчка может быть информацией или данными.

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

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

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

Это объяснение приводит нас к старой, существующей системе. Вы видите, что следующим отрезвляющим шагом будет начать спрашивать себя, с какими задачами мы можем столкнуться в будущем. Не только мы, но каждая функция компании. Итак, мы совершили удачный прыжок к следующему этапу — попытка определить часть данных/информации которые могут потребоваться. Отсюда один шаг, чтобы потратить все свои силы на определение подходящих форматов данных, процедур запроса и т. п. … Сейчас это уже нахоженная тропа. Те же методы, только акцент на формате выходных данных. Эти многотомные отчеты пытаются дать ответы на все возможные вопросы. Конечно, в последние годы возможности персональных компьютеров и on-line запросов несколько расширилась, что устраняет данное явление, но, не учитывая, как это делается.

В Израиле есть одна байка, истинность которой я не могу проверить, но не очень удивился бы, если бы такое случилось на самом деле. 10 лет назад одним из путей извлечения информации из компьютера были печатные отчеты. Тогда центральный вычислительный центр израильских вооруженных сил рассматривал новую технологию лазерной печати, как панацею для решения всех проблем. Капитан этого отдела, вероятно очень недалекий, решил справиться с нашей задачей весьма оригинальным способом. Безо всяких объяснений он издал инструкцию убирать из очереди печати все отчеты, содержащие более 100 страниц. В то время, когда компьютерная децентрализация существовала только в мире идей, множество копий отчетов рассылалось из центрального отдела в несчетное количество армейских подразделений. Эпилог легенды говорит, что была всего лишь одна жалоба на это решение. Человек, который прислал ее, занимался подшивкой отчетов в архивные папки.

Каждый менеджер большой организации может иметь отношение к этой легенде. И даже если эта история лишь байка, она недалека от реальности. Что было нашей изначальной жалобой? Мы тонем в океане данных. Ситуация сегодня настолько удручающа, что на всех публичных выступлениях, где я предлагаю связывать принтеры напрямую с редакторами, следует смех и улыбки. Наверно где-то в рассуждении мы приняли неверное заключение. Где-то должна быть логическая нестыковка. Информационные системы не могут исключать необходимости банков данных, но, несомненно, информационные системы это совершенно другие сущности. Если они должны быть эффективными, они просто не могут идентифицироваться с существующими банками данных.

Давайте вернемся к моменту, где мы пытались разграничить понятия данных и информации. Мы пытались определить информацию как данные, которые необходимы для принятия решения. Само это определение не дает нового понимания, но не смотря на это, уже интуитивно понятно, что информация может определяться только в контексте принятия решения. Может информация определяется не как «данные, требуемые для ответа на вопрос», а как сам «ответ на заданный вопрос»?

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

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

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

2. Чего пытается достичь компания?

«Качество ґ- в первую очередь». «Производственные запасы — замороженные деньги». «Сбалансированный поток вместо полной загрузки[2]». Это всего лишь некоторые из девизов, которые скандируются организациями индустриального менеджмента. В восьмидесятых годах мы стали свидетелями трех могучих течений менеджмента — Всеобщее управление на основе качества (TQM), Точно вовремя (JIT) и Теории ограничений (TOC)[3], которые бросили вызов почти всему, что раньше принималось за аксиому. Все эти течения скромно начинали как локальные технологии. Сейчас все они распространяются со скоростью звука.

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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