Автор статьи: Алексей Федоров
>
хороший академический вопрос — каково число измерений населяемого нами континуума. Интересно, что ответ, который давали на него физики и философы, сильно менялся в ходе того, что называется "прогрессом" (что, кстати, заставляет с сомнением относится к окончательности последнего варианта).
Бизнесмены же не меняли свой взгляд никогда. И в Византии, и сейчас они знают твердо: у всего существующего есть ровно два значимых универсальных измерения — время и деньги. Поговорим о них.
Время внедрения
итак, сроки. На сакраментальный вопрос: "Я хочу автоматизировать то-то и то-то, как быстро вы мне это сделаете?" Как правило, следует сакраментальный ответ: "Давайте, уточним, что именно вам нужно. Ответ будет зависеть от этого." Вопрос — правильный. Ответ — нет. На самом деле, — сроки внедрения в первую очередь определяются не сложностью задачи. Сроки внедрения определяются СКОРОСТЬЮ ПРИНЯТИЯ РЕШЕНИЯ ЗАКАЗЧИКОМ (при профессионализме внедренца, разумеется).
Пример. Допустим, есть некто, кто хочет вылечиться от некоей болезни, лечение которой связано с операцией. (Аппендицит? — пусть). Время работы специалиста (врача) — 1-3 часа операции плюс минут двадцать в день на обход и около часа-двух на процедуры. Просуммируйте и сравните с общим временем нахождения больного в клинике (недели две, если все в порядке, а если и нет, то доля времени, которое тратят на больного врачи относительно времени его пребывания в стационаре почти не увеличивается — просто больной не выписывается, а процедуры не прекращаются). То есть, для конкретно взятой болезни, при конкретном медколлективе, время выздоровления может измениться в несколько раз в зависимости от пациента! Короче, напрашивается следующий вывод- время выздоровления определяется, в первую очередь, состоянием больного, которого лечат, а не тем временем, которое уделили больному врачи.
Теперь про автоматизацию. Постановка задачи на автоматизацию зависит (сильно) от той среды, в которой будет происходить автоматизация. Информационные потоки нельзя проектировать в отрыве от среды их воплощения. Еще конкретнее — постановка задачи процентов на… (много!) определяется тем средством, которое будет выбрано для решения. Ставить задачу будет руководство вашего предприятия и предметные специалисты. Как хорошо они представляют средства, с помощью которых задача будет решаться? Вопрос риторический. На самом деле, постановка задачи на автоматизацию системы управления (предприятием, функциональной областью деятельности или конкретным бизнес-процессом)- это процесс, в котором принимают РАВНОПРАВНОЕ участие две стороны — внедряющая фирма, которая (как предполагается) хорошо владеет средствами автоматизации, и специалисты вашей фирмы. В процессе внедрения последним придется узнать гораздо больше нового, чем специалистам внедряющей фирмы (говорим о настоящем!). Вывод тривиален — время, которое придется затратить специалистам и руководству вашего предприятия на выбор оптимальной схемы информационных потоков и бизнес-процессов (ведь решение принимать им, а не внедренцу), существенно больше того времени, в течение которого специалистам внедряющей фирмы (повторюсь, если они настоящие), придется разбираться в нюансах бизнес-процессов вашего предприятия для подготовки вариантов этих схем.
Пример. Время, в течение которого мы ставили и автоматизировали комплексную систему управления предприятием (автоматизация систем планирования, учета, контроля и анализа) одному из наших Заказчиков, составило три месяца. Время, в течение которого мы ставили и автоматизировали подсистему расчета зарплаты другому нашему Заказчику (оба сравнимы по количеству персонала) составило полгода. Подчеркну, время автоматизации аналогичной подсистемы в первом случае заняло бы 2 недели. И в том, и в другом случае работали одни и те же наши специалисты. В чем разница? В скорости принятия решения Заказчиком. В первом случае речь шла о коммерческом предприятии с жестким механизмом управления и слаженной, заинтересованной в результате командой, во втором — о постсоциалистическом предприятии с богатой наследственностью.
иными словами, хорошая внедряющая фирма должна, как минимум, "не тормозить" процесс автоматизации больше, чем сам Заказчик. Аналогичная формулировка в медицине может звучать примерно так — хороший врач, как минимум, не должен "тормозить" процесс выздоровления больного.
Если же вернуться к вопросу, с которого начали, — "сколько времени займет внедрение?", то после 2-4 встреч с руководством фирмы-Заказчика, каждая продолжительностью около часа, время внедрения можно будет оценить с погрешностью около 40%. На этом этапе уже станет ясна и примерная сложность задачи, и то, как и сколько времени Заказчик реагирует на предложения и вопросы, сколько у него ответственных, существует ли ясный механизм принятия решения и т.д. Продолжая медицинские аналогии, серия этих встреч — не что иное как бесплатное предгоспитализационное обследование (общий диагноз, выявление всяких аллергий, противопоказаний и проч.).
Деньги внедрения
Сколько стоит внедрение? Автоматизация — это бизнес. Обычный, нормальный бизнес. Значит, определение стоимости процесса описывается общими экономическими законами — без чудес. Трудовая теория формирования стоимости (да-да, старые добрые Адам Смит с Карлом Марксом) — это классика. По ней и по жизни — прибавочная стоимость создается наемным трудом. В нашем случае трудом специалистов внедряющей фирмы. Значит, труд среднего специалиста средней внедряющей фирмы объективно определяется временем его работы. Поэтому у каждой внедряющей фирмы единица трудозатрат определяется квалификацией персонала — эта единица является базой для расчета. А как на практике устанавливается стоимость внедрения? Нам известно три способа договорного определения стоимости внедрения.
Способ 1. Авантюрный.
Внедрение всегда производится с целью оптимизации бизнеса, и результатом внедрения будет увеличение прибыли автоматизируемого предприятия либо за счет расширения бизнеса, либо за счет сокращения потерь, либо за счет и того и другого. Вот на некоторую долю того прироста прибыли, который должен быть результатом автоматизации, стороны и договариваются. Этот способ достаточно редок — и правильно. Автоматизация не терпит авантюр. Поясняю. Солидная внедряющая фирма на это никогда не пойдет по следующей причине — нести прямые затраты ей придется сейчас (время, которое специалисты фирмы потратят на внедрение), а окупятся ли они в будущем или нет, будет зависеть от персонала автоматизируемой фирмы. То есть, проконтролировать этот процесс будет нельзя. Риск огромен.
Способ 2. Проектный.
Способ, любимый руководством автоматизируемых предприятий за кажущуюся простоту и ясность. Нет, способ, действительно, ясный, но вот последствий этой ясности Заказчик себе, как правило, не представляет. И это может привести к серьезным проблемам.
Коротко суть проектного способа определения стоимости внедрения. Стороны четко оговаривают, что, в какие сроки и за какие деньги будет сделано. Серьезная внедряющая фирма формализует это в договорных документах следующим способом: Постановка задачи определяет, что именно должно быть сделано; ТЗ определяет, как должно быть сделано то и только то, что определено в Постановке; Кодирование — кодируется то и только то, что определено в ТЗ. Такая система позволяет внедряющей фирме точно определить себестоимость и стоимость проекта, а также планировать ресурсы. НО! Что произойдет, если после подписания договора и Постановки задачи Заказчик вдруг обнаружит, что по какой-либо причине стоящие задачи изменились таким образом, что часть заявленных в Постановке задач в том виде, в каком они акцептованы внедренцем, ему УЖЕ НЕ НУЖНА?! Внедряющая фирма на основании подписанных простых и ясных документов имеет полное право (по крайней мере, доказать это в любой инстанции не составит труда) сделать ненужную работу и добиться оплаты ее договорной цены. Кроме того, коль скоро сроки работ определены, то внедряющей фирме не выгодно их растягивать — норма прибыли уменьшается, и она обязательно будет использовать подписанные документы с оговоренными сроками для того, чтобы не дать Заказчику затянуть сроки (увеличить скорость принятия решения Заказчиком).
иными словами, при проектном способе реальную ответственность берут на себя обе стороны, но одна из сторон редко отдает себе в этом отчет.
Способ 3. Рамочный договор о сотрудничестве.
Жизненность этого способа определяется его гибкостью. Если после предварительных 2-4 встреч с руководством (помните, — в начале статьи?) задачи, сроки и, следовательно, стоимость внедрения можно оценить с погрешностью до 40%, то после этапа постановки задачи ситуация определяется с погрешностью до 10%. В зависимости от того, на каком этапе при проектном способе работы принимается решение о проекте, Заказчик рискует "попасть" либо в эти 40, либо в те 10 процентов риска. В отличие от проектного способа стороны констатируют общее видение предполагаемых задач, сроков и стоимости, но фиксируют лишь те задачи и этапы работ, которые им ясны на 100% (принимая на себя двустороннюю ответственность), и договориваются о том, что новые задачи будут формулироваться и выполняться оговоренным способом по мере их прояснения. И так до тех пор, пока окончательная цель не будет достигнута. меньшая жесткость — меньший риск. Возможность внесения оперативных корректировок гарантирует меньший расход ресурсов (они не тратятся на выполнение ненужной работы), а значит, гарантирует лучшее, по сравнению с проектным способом, соотношение результат/цена.
Пространство статьи, к сожалению, не позволяет рассмотреть все нюансы обсуждаемых вопросов, но 26, 27, 28 октября мы проводим семинары, на которых расскажем все подробности, приходите сами, приводите руководство. На этом я хочу завершить рассмотрение сухих экономических и организационных аспектов внедрения. В следующей статье речь пойдет о конкретной реализации новых идей в КИС. Обещаю — будет интересно.
Без обмана, так без обмана. Хочу извиниться. В предыдущей статье была допущена ошибка. Не сознательная (а, кстати, интересно, — многие ли из читающих ее заметили?) — в пункте, касающемся должностных инструкций, было сказано о том, что пункты 4 и 5 можно распараллелить. Просто ужас! Пункт 4 (ТЗ) и пункт 5 (кодирование)?! НИ В КОЕМ СЛУЧАЕ!!! Описка — можно распараллелить пункты 5 и 6 (кодирование и создание должностных инструкций). Извините.
Источник http://www.intalev.ru
