astikhin: (Default)
[personal profile] astikhin



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

Для того, что бы был более понятен механизм "провала операции" ее надо рассмотреть во всех деталях. Итак, предположим, некая компания Z решила что она жить не может без какой-нибудь супер-навороченной системы планирования ресурсами (управления предприятем) или, на худой конец, системы документооборота. С чего обычно начинается проект? Как правило с подбора непосредственно системы, которую планируют внедрять на предприятии и с подрядчиков, которые могут выполнить работы в полном объеме и еще взять систему на гарантийную поддержку.

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

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

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

Теперь самое интересное - понимание того, как работают внутренние информационные потоки. Вот здесь-то обычно и выясняется, что вообще мало кто на предприятии понимает общий производственный цикл и может внятно объяснить, что "здесь-вот-так-вот, а здесь - вот-так-вот". Если таких людей нет - получается как в примере с судами штата Калифорния, если есть - то выходит некая "лоскутная" автоматизация разных подразделений, а затем "допиливание напильником" (еще не самый худший вариант) и интеграция в общую рабочую среду.

Вывод - чем больше ответов на начальном этапе работы над проектом - тем меньше вопросов к самому проекту перед его сдачей в эксплуатацию и в ходе последующей поддержки.


Date: 2012-04-04 04:50 pm (UTC)
From: [identity profile] sergeyvi.livejournal.com
Вы по сути правы, но я бы советовал ссылаться на более стогую методологиию, ну скажем ISO 15926 и всяческие V-диаграммы, которые действительно снижают риск неправильной постановки задачи.

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

Date: 2012-04-04 05:30 pm (UTC)
From: [identity profile] astikhin.livejournal.com
> Вы по сути правы, но я бы советовал ссылаться на более стогую методологиию, ну скажем ISO 15926 и всяческие V-диаграммы, которые действительно снижают риск неправильной постановки задачи.

У меня был ответ "общего плана", исходя из своего собственного опыта и опыта смежников :) Хотя, по сути дела, использование стандартов, рекомендаций и методологий лишь _помогает_ описать поставленную на реализацию задачу и не заменяет собой _понимание сути_ происходящих на предприятии бизнес-процессов.

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

Да, к сожалению, не без этого. Со своей точки зрения (как технических специалист) долго не мог понять - откуда в айтишных и около-айтишных кругах появилсь понятие "шаманство с бубном". Понятно, конечно, что это описание непонятных действий, но все же - откуда это появилось? Нашел ответ на этот вопрос, с моей точки зрения, в книге Торстейна Веблена "Теория праздного класса", а если быть точнее - то в главе, описывающий "анимистическое восприятие" действительности.

http://astikhin.livejournal.com/88248.html

В принципе, вывод автора очень простой, но это как раз тот случай, когда именно простота маскирует все трудности. Дело в том, что если человек _не понимает_ процессов, происходящих в мире (в нашем случае - в производстве) - он начинает "объяснять" это некими "высшими силами" и "магией" и, самое главное, не может _управлять и оптимизировать_ протекающие процессы.

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

Profile

astikhin: (Default)
astikhin

December 2020

S M T W T F S
  12345
6789101112
13141516171819
20212223242526
27282930 31  

Style Credit

Expand Cut Tags

No cut tags
Page generated Jun. 12th, 2025 01:38 am
Powered by Dreamwidth Studios