Любую деятельность можно описать в виде процесса, так как сама жизнь - это движение. Другой вопрос, что движение может быть упорядоченным и структурированным, а может - хаотичным. Да, конечно, есть теории управления хаосом, но тогда это уже будет не хаос.
Управление процессами в российских организациях, к сожалению, слабо развито. Большинство из них не имеют четко прописанных процессов, даже в части ключевых, определяющих ценность существования. Такие организации работают "как получается" и "как приходится". Так как нет структурирования, то и оптимизировать такие компании не представляется возможным. Если возникает необходимость автоматизировать деятельность, то происходит это бессистемно и хаотично. В результате полученное ПО громоздкое, неуправляемое и не имеющее шансов на развитие - нет единой структуры, нет системы. Поэтому чаще всего ситуация, когда приходится все ломать и делать заново.
Радует одно. Что рано или поздно руководство компании приходит к выводу о необходимости структурирования деятельности организации и описании (а вернее моделировании) хотя бы основных, ключевых, бизнес-процессов.
Когда же вопрос стоит только в автоматизации, то часто бывает так, что как таковых процессов нет - их нужно еще создать. А компания уже как-то существует и функционирует. О такой природе деятельности говорят, как о "культуре героев" - все держится на энтузиазме создателей, где в случае ухода "ключевых сотрудников" рушится все - хрупкое здание, в котором невозможно разобраться последователям. А задача автоматизировать стоит остро, так как потери катастрофически большие и, кажется, что автоматизация - это панацея. Но автоматизировать хаос - порождать новый хаос, а не оптимизацию.
К сожалению, заказчик этого чаще всего не видит, в силу отсутствия системного мышления или привычки к тому способу работы, который уже каким-то образом сложился, интуитивно выбранным. И здесь в работе с заказчиком и кроется очередная трудность: "Отсутствие понимания границ процесса - где точка отсчета и где окончание процесса."
Заказчик, как говорилось ранее, решает срочные текущие задачи, ему некогда думать о перспективах. Как часто приходится слышать - "Автоматизируйте, пожалуйста, только вот эту часть! Остальное - слишком долго. А нам нужно срочно!" И не важно заказчику, что то, что он хочет не будет работать корректно без создания предыдущих десятка действий процесса, или и вовсе является прямым результатом этих обязательных действий - всего лишь результатом. Так меня просили автоматизировать... отчеты!! деятельности, которая даже не описана и не существует в действительности!
Другая крайность, когда заказчик четко не представляет границ собственных функций, полномочий и ответственности (такое тоже часто бывает) и не может определиться, где кто и что делает. А когда ответственные не определены, то и поле деятельности остается заброшенным и ничьим. Или наоборот, процесс превращается в некую амебу - без формы и четких границ.
Управлять таким процессом сложно (если это вообще возможно). В хорошо продуманном процессе всегда есть входные данные и выходные данные - начало и конец, и если изменять входные параметры, то тут же меняется вся система - согласно выстроенной логической цепочке. В противном случае, перед нами не система, а набор раздробленных и плохо связанных с собой операций, где возможно есть и пробелы, и "петли".
Когда заказчик не доверяет авторитету разрабатывающему процесс или специалисту по автоматизации, то крайне сложно с ним вести конструктивный диалог о необходимости выстраивать корректную систему с четкими границами и параметрами, при чем целиком, а не кусочками и в произвольном порядке. Никто же не считает разумным возможность сначала сфотографироваться в костюме, прежде чем его сшили! Это очевидная глупость. Но, когда речь заходит об автоматизации, такие решения не редкость.
Причина простая - люди не видят картины целиком и не понимают, что такой запрос также абсурден предыдущему примеру. Вот, почему хорошие программисты предпочитают получить полное техническое задание, чтобы можно было его проанализировать и понять, как его реализовать, а не кусочками - есть риск, что кусочки потом не "склеются".
Заказчик, как говорилось ранее, решает срочные текущие задачи, ему некогда думать о перспективах. Как часто приходится слышать - "Автоматизируйте, пожалуйста, только вот эту часть! Остальное - слишком долго. А нам нужно срочно!" И не важно заказчику, что то, что он хочет не будет работать корректно без создания предыдущих десятка действий процесса, или и вовсе является прямым результатом этих обязательных действий - всего лишь результатом. Так меня просили автоматизировать... отчеты!! деятельности, которая даже не описана и не существует в действительности!
Другая крайность, когда заказчик четко не представляет границ собственных функций, полномочий и ответственности (такое тоже часто бывает) и не может определиться, где кто и что делает. А когда ответственные не определены, то и поле деятельности остается заброшенным и ничьим. Или наоборот, процесс превращается в некую амебу - без формы и четких границ.
Управлять таким процессом сложно (если это вообще возможно). В хорошо продуманном процессе всегда есть входные данные и выходные данные - начало и конец, и если изменять входные параметры, то тут же меняется вся система - согласно выстроенной логической цепочке. В противном случае, перед нами не система, а набор раздробленных и плохо связанных с собой операций, где возможно есть и пробелы, и "петли".
Когда заказчик не доверяет авторитету разрабатывающему процесс или специалисту по автоматизации, то крайне сложно с ним вести конструктивный диалог о необходимости выстраивать корректную систему с четкими границами и параметрами, при чем целиком, а не кусочками и в произвольном порядке. Никто же не считает разумным возможность сначала сфотографироваться в костюме, прежде чем его сшили! Это очевидная глупость. Но, когда речь заходит об автоматизации, такие решения не редкость.
Причина простая - люди не видят картины целиком и не понимают, что такой запрос также абсурден предыдущему примеру. Вот, почему хорошие программисты предпочитают получить полное техническое задание, чтобы можно было его проанализировать и понять, как его реализовать, а не кусочками - есть риск, что кусочки потом не "склеются".
Задача же "собрать пазл" в условиях высокой неопределенности не из легких, но возможна. Для этого необходимо системное мышление и методы индукции и дедукции, где самое сложное определить точку отсчета и конечный результат.
Я использую следующий способ - с помощью коучинга выясняю у заказчика конечный результат действия (не отчет) и как-бы "разматываю" процесс назад, отступая "от картины" ровно столько шагов, чтобы обозреть ее целиком - найти исток и изначальные входные данные. При этом, необязательно видеть мельчайшие детали - их объем на этом этапе может только сбить с толку (что важно, а что второстепенно, и возможно, переменно).
И когда общий контур получен (границы процесса), можно (и нужно) заняться детализацией и анализом уже известного процесса. Уровней глубины детализации (декомпозиции) может быть столько, сколько нужно для однозначного описания, понятного программистам - разработчикам.
Как же объяснить это заказчику?
Во-первых, конечно, у вас должен быть заслуженный авторитет. Или кто-то с хорошим авторитетом, мог бы вас поддержать.
Во-вторых заказчик никогда не хочет чувствовать себя глупым или необразованным (даже если он, действительно, ничего не понимает). Поэтому нужно выстраивать так коммуникации, чтобы не задеть его самолюбие. Используйте простые понятные слова и не скупитесь на разъяснения - лучше потратить несколько часов на "обучение" заказчика, чем потом тратить его на бесконечные бесплодные и выматывающие вас (и заказчика) споры.
В-третьих не сдавайтесь, махнув рукой, напору заказчика - результат будет плачевным, как вы и предполагали, но тень упадет на вашу репутацию, даже если все было прописано в договоре и к вам претензий, в принципе нет.
В-четвертых используйте методы аргументации.
В-пятых верьте в себя! И все у вас получится :).
Ну, а если заказчик все-таки упертый и стоит на своем вопреки здравому смыслу, то я бы не стала брать такой проект на себя.
Если вам это интересно, подписывайтесь, чтобы получать уведомления о продолжении.
Также буду благодарна вашей обратной связи и вопросам. Пишите и я отвечу!
To be continued...
Всегда ваша,
Денисова Елена.
Комментариев нет:
Отправить комментарий