Методика предпроектного обследования

By Leo on Вторник, Август 01, 2000 - 12:00:

Уважаемые all!!
Помогите найти какую нибудь ссылку по методике проведения обследования предприятия с большой организационной разветвленностью.
Как после проведения обследования на нижних уравнях переходить к увязке в единый Б-процесс по вертикале?
Заранее блогадарен

By Александр on Вторник, Август 01, 2000 - 12:00:

Уважаемые Господа!
Предлагаю поделиться определением понятия КИС для машиностроительных предприятий. Интересно рассмотреть иерархическую модель КИС, основанную на стандартах (типа 7 уровней OSI в ычислительных сетях). По моим представлениям существует не менее 14 уроней. Например: верхний уровень ERP существует на основании самодостаточных стандартов нижнего уровня типа SCM, FRP, TQM, CSRP и т.п.

By r5+ on Вторник, Август 01, 2000 - 12:00:

А кому нужна "иерархическая модель" ?
Что с ней делать ?

By Сергей Колесников on Вторник, Август 01, 2000 - 12:00:

Вообще идея правильная!

Именно так и нужно осуществлять выбор и разработку систем.

У меня на эту тему есть довольно много слайдиков, надо подумать как их разместить.

МоЖет в виде статьи?

А вообще всех - с НОВЫМ НОВЫМ годом

By lmd on Вторник, Август 01, 2000 - 12:00:

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

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

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

By Мазуркин Сергей on Вторник, Август 01, 2000 - 12:00:

Предпроектное обследование - по определению, обследование перед проектом.

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

Можно утверждать, что знания заказчику нужны с некоторой, наперед заданной, точностью (например, +-месяц, +-день, +-час) и с некоторой, наперед заданной, детализацией (до отдела, до рабочего места, до операции)

Задача предпроектного обследования - достигнуть понимания в терминах КИС цели, способов достижения цели, необходимых для достижения цели ресурсов.

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

Как следствие отчуждаемости - предпроект позволяет синхронизировать знания и цели участников проекта. Еще одно следствие отчуждаемости - при желании можно провести верификацию (аудит).

Материальный, отчуждаемый носитель понимания - отчет о предпроектном обследовании.

Аналог - финансовая отчетность. Это отображение финансовой деятельности. Фин.отчетность среди прочего должна обладать свойством отчуждаемости. Создание фин.отчетности достаточно трудоемко. Однако по причине трудоемкости от нее не отказываются. :-)

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

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

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

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

Вернемся к нашим баранам. Кто специалист в области автоматизации - ты или Заказчик ? Не проще-ли Заказчику молча доверится специалисту (ам)?.

Я специально обостряю тему , безусловно истина посредине. Продолжим ?

By Мазуркин Сергей on Вторник, Август 01, 2000 - 12:00:

Хорошо, Олег, будем на ты.

Первое
Пусть будет стоматология.

Когда приходишь к дантисту, ты примерно представляешь какие услуги и каким образом тебе будут оказаны.

Приходя к дантисту ты знаешь что спросить. Ты спрашиваешь сколько стоит пломбирование, сколько удаление, какая пломба, сколько будет стоять. Так? Т.е. знаешь по крайней мере половину ответа.

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

Теперь возьмем твою ситуацию.
"...приходишь к дантисту. Зубки запущены. Дантист проводит обследование , рентген (предпроект).Что он делает дальше ?"

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

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

Заметь, что:
1. на детальный уровень врач не уходит (действительно о парадантозе мало кто говорит)
2. врач отчуждает результаты обследования (обсуждает результаты с пациентом)
3. предлагает решения и делает обоснование предлагаемых решений
4. окончательное решение принимает пациент (заказчик)

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

"Вернемся к нашим баранам"
Вернемся. Представь, что дантист проводит обследование. Ему все понятно. "Зубки запущены". Делает общую анестезию и ...удаляет запущенные зубы.

Он как специалист прав. Запущенные зубы тебя больше не беспокоят. Решение дешево и выполняется быстро (в одно посещение).

Второе
Такие аналогии с другими областями возможны когда можно сопоставить области. Согласись, что сравнение со стоматологией возможно только в том случае, если представить, что заказчики осведомлены в IT-вопросах также как рядовые пациенты в стоматологии.

Чаще всего не так. Заказчики чаще всего не представляют что надо спрашивать. Иногда даже не знаю чего хотят. Обычное дело, когда заказчик не сообщает конечной цели автоматизации (например, для обеспечения сохранности конфиденциальных данных).

Теперь представь. Ты приходишь к зубарикам (название ты знаешь примерно). Хочешь, иметь здоровые зубы (как у героев в сериалах). И говоришь врачу - сделай мне зубы. Если врач начнет лечение без согласования, то он скорее всего...

Вернемся к заказчикам.
С одной стороны, готов утверждать, что обычные заказчики систем автоматиазации мало осведомлены в области автоматизации.

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

Поэтому отчасти ты прав. Некоторые подробности можно опускать из обследовния. Но... осторожненько. Наверное, лучше перебдеть, чем недобдеть :-) Готов утверждать, что будет лучше и заказчику, и проектировщику.

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

Заказчик использует отчет для того, чтобы принять основополагающие решения. Проектировщик использует отчет как план действий.

Если отчет позволяет провести верификацию (правильно составлен), то и заказчик, и проектировщик могут использовать отчет в спорных случаях.

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Критику принимаю.Просто наболело...
Мое глубокое убеждение заключается в том, что предпроект должен содержать Я С Н Ы Й образ внедренной (!) и успешно (!) функционирующей КИС.
Это мое кредо в проведении предпроектных работ.
Как очень точно подмечено в одной из статей этого сайта : "Предпроект-это платное ознакомление Заказчика (или Проектировщика) с тем, как работает его предприятие".
В 80 % случаев предпроектная документация (по крайней мере по моим наблюдениям) состоит из очень детального лингвистического описания деятельности предприятия Заказчика с массовым цитированием учебников по бухучету, финансам и т.д. Ну а в конце , на десерт - долгожданная
"Постановка задач по автоматизации". Понятно, что такая документация вызывает по крайней мере недоумение Заказчика.
Приятным подарком для меня стала статья Сергея Колесникова по Системе Концептуального Проектирования (я не путаю автора ?).
Собсвенно, проблема заключается в том, как научить системных аналитиков-проектировщиков системному подходу (или уму ?).
Ваше мнение ?

By ppv on Вторник, Август 01, 2000 - 12:00:

Господа,
Вы спорите, значит вам интересен предмет. Внесу ясность.
Предприятие - это организм. В развитии предприятия его жизнь. Развитие невозможно без изменений. Изменения должны быть адекватны обстоятельствам и условиям. Изменения должны быть адаптивными. У кого быстрее реакция на изменения и короче цикл осуществления изменения тот быстрее учится, он обгонит медленного, а затем его съест.
Короче. Предприятию надо научиться глубже понимать окружающее и знать собственный организм, надо научиться изменяться быстро и адаптивно. Для этого управление должно быть предельно гибким, а применяемая для управления модель предприятия и модель ближнего окружения предприятия должны быть огкрытыми к пополнению и изменению. Причём модель предприятия должны быть частью модели предприятия с окружением. Одна и та же модель должна быть предметом и предпроектных исследований и проекта будущей информационной компоненты системы управления предприятием (более строгий эквивалент часто употребляемой абревиатуры "КИС" с неоднозначным смыслом). Если модель открыта к пополнению и к изменению содержания, то нет проблем с уточнением модели по-месту и по-необходимости и соответственно нет проблем с гибкостью управления предприятием на основе меняющейся же модели.
Как построить такую открытую модель? Только не на алгоритмах. ну это отдельная история. Спрашивайте, расскажу.
Александр

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Александр, я правильно понял, что в замене цепочки
ПРЕДПРОЕКТ-ПРОЕКТ-ВНЕДРЕНИЕ-РАЗВИТИЕ
на
ПРОЕКТ-ВНЕДРЕНИЕ-РАЗВИТИЕ
есть доля здравого смысла ?

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Вдогонку...
Александр, конечно интересно, как построить открытую модель. Поделись теорией.
А есть у тебя практика ?

By Мазуркин Сергей on Вторник, Август 01, 2000 - 12:00:

Приветствую Александр.

Присоединяюсь к вопросам Олега. Послушать действительно интересно.

По высказанному утверждению:
Предприятие - это организм. В развитии предприятия его жизнь. Развитие невозможно без изменений. Изменения должны быть адекватны обстоятельствам и условиям. Изменения должны быть адаптивными. У кого быстрее реакция на изменения и короче цикл осуществления изменения тот быстрее учится, он обгонит медленного, ...
Согласен.
Возвращась к предпроектному обследованию, можно сказать, что в этой метафоре предпроектное обследование выполняет роль глаз. Оно позволяет "увидеть" проблемы и пути решения.

Будет ли увиденное правильно проинтерпретировано, с одной стороны, сильно зависит от мозга организма, с другой стороны, зависит от совершенства глаза.

О цепочках "ПРЕДПРОЕКТ-ПРОЕКТ-ВНЕДРЕНИЕ-РАЗВИТИЕ" / "ПРОЕКТ-ВНЕДРЕНИЕ-РАЗВИТИЕ". Вообще говоря, интересная ветвь обсуждения не хотелось бы терять.

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

К сожалению, в течение нескольких дней меня не будет в Москве. Не знаю будет ли у меня доступ к форумам. Однако, постараюсь следить за ходом обсуждений. Так что не теряйте меня.

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

ПРЕДПРОЕКТ - атавизм, тупиковая ветвь развития.

ПРОЕКТ - согласованный с Заказчиком комплекс мероприятий, объединяющий комплексное обследование предприятия с построением модели "КАК БУДЕТ В ИС", выработкой базовых концепций построения ИС, грубым макетированием ключевых процессов, дальнейшей тонкой настройкой макета и разработкой проектной документации.

Проектная документация:
1) Концептуальная часть (70 % "ясности")
2) "Тонкая" часть (30 % "ясности")
3) Описание построенной системы (снимок готового макета)
4) Предложения по развитию

Примечание.Для особо упорных заказчиков строится модель "как есть" только по ключевым процессам и концепциям для сравнительного анализа.

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

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

By Mikael Gorsky on Вторник, Август 01, 2000 - 12:00:

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

Хватит на сегодня. Сергею успешной командировки.

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Ну, не боги горшки обжигают. Решать проблемы Заказчика приходится именно нам - проектировщикам (не в смысле разработчиков), внедренцам. Кстати, проблемы заказчиков решают не специальные фирмы, а конкретные люди. Приходилось видеть и глупые эксперные заключения умных фирм и умные проекты конкретных людей, без принадлежности к "умной" фирме. И Заказчик далеко не дурак, когда прислушивается к мнению внедренцев.
"Внедрятель"- это что-то мелкое.
По Далю, внедрение - "НАСИЛЬСТВЕННОЕ ПРОНИКНОВЕНИЕ ИНОРОДНОГО ТЕЛА В СРЕДУ, СОПРОТИВЛЯЮЩУЮСЯ НАСИЛЬСТВЕННОМУ ПРОНИКНОВЕНИЮ".
Если мы внедряем умному заказчику в таких условиях, не такие уж мы и неумные .

С уважением.

By Смок on Вторник, Август 01, 2000 - 12:00:

Вообще-то Майкл прав - дискуссия довольно своебразна.
"Generic" задача предпроектного обследования -
определить соответствие предполагаемого метода рещения задачи обьекту. И если выявлены явные несоответствия - то быстро принять решения по устранению проблем, дабы избежать краха проекта.
Реально это никто не делает.
Участники дискуссии априори считают, что задача стоящая перед ними - решаемая. В этом случае собственно ППО не требуется.
Таким образом обсуждается сравнительно честный метод отьема денег у клиента.

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Господа !
Кто-то кого-то завел в тупик. Речь идет не о ненужности ПРЕДПРОЕКТА как класса, а об ВОЗМОЖНОСТИ объединения стадии предпроектного обследования и собственно проектирования. Разве это крамольная цель ? Эта идея нарушает стройную концепцию сайта ? Знаете-ли Вы , сколько длятся проекты, развиваемые по схеме ЭКСПЕРТИЗА-ПРЕДПРОЕКТ-ПРОЕКТ-ВНЕДРЕНИЕ ?
Я думаю, что знаете.
Майкл, ты не прав. Сообщения, не соответствующие тематике конференции, нужно просто удалять, а не отвечать на них.
С уважением.

By ppv on Вторник, Август 01, 2000 - 12:00:

Ребята,
Спасибо за активность.
Я не стану ни агитировать за необходимость предпроекта, ни за его ненужность. Я считаю, что и предпроект, проект и само осуществление проекта суть части единого процесса развития культуры управления предприятием. Это то же развитие предприятия, но с привлечением внешних ресурсов как наиболее подготовленных (знания есть и время оплачивается). А разработка предпроекта и проекта посвящены созданию VISION и плана движения.
Развитие предприятия заключается в определении (обосновании) цели, в определении (обосновании) пути и в прохождении намеченного пути. Я за стратегию непрерывных небольших улучшений. Цикл за циклом. Выполнять малые и сверхмалые контрактики совместно с внешними консультантами и интеграторами, учиться у них, перенимать опыт и технолоии, а затем самостоятельно ставить цели и определять пути (это самое интимное), а исполнение заказать вовне, и наконец масштабное делать самостоятельно.
Я полагаю, что в России продавать ЕМЕЛИНЫ ЩУКИ или делать заплатки на заплатки преступления. Покупатели-то найдутся. Награмотных или глупых много. Но в массе своей российские предприятия могут опираться только на собственный труд, так как денег на покупки "тиражного" у них нет и нужных денег не заработать (замкнутый круг: чтобы заработать и купить, надо улучшить управление, а чтобы улучшить управление, надо заработать и купить).
Итак, нужно строить, наполнять нужными знаниями и передавать предприятиям технологии поддержки их саморазвития. Это похоже на сопровождение предприятия консультантом, способным передавать предприятиям не только знания, но и технологии (это часть деятельности интеграторов).
Вот так, ребята.
А про устройство открытой модели я вышлю информацию на почтовые ящики интересующихся, т.к. объём немалый для публикации на форуме.
Удачи всем.

By Mikael Gorsky on Вторник, Август 01, 2000 - 12:00:

Олегу Смирнову:
Возможность объединения обследования с проектированием - именно это и есть криминал (по моему мнению, разумеется), а отнюдь не способ сэкономить время, как вам кажется. Ибо после обследования вы предоставляете заказчику (можно я не буду выделять важные слова БОЛЬШИМИ буквами?) самому или вместе с вами принимать решение о выполнении проекта. Повторюсь, важно это еще и потому, что груз ответственности за это решение сожет выдержать только заказчик. Объединяя же эти два этапа, вы намеренно лишаете заказчика возможности самостоятельно направлять проект. (см. мое предыдущ. сообщ.)

Александру Попову:
Злоупотребляя служебным положением, предлагаю вам текст "об устройстве открытой модели" прислать нам, а мы его напечатаем в КРУ. Если хотите, конечно. С нас - литературная обработка (если потребуется).

By Алексей Важнов on Вторник, Август 01, 2000 - 12:00:

Мне кажется, что без предпроекта не обходится ни одна более-менее серьезная работа. Без предпроекта можно только системы типа "Консультант" ставить.

Олег Смирнов написал:
> ПРОЕКТ - согласованный с Заказчиком комплекс мероприятий, объединяющий
> комплексное обследование предприятия с построением модели "КАК БУДЕТ В ИС",
> выработкой базовых концепций построения ИС, грубым макетированием ключевых процессов

Сознательно обрываю цитату здесь. Это скорее определение ПРЕДПРОЕКТА.
Поскольку многие вещи не детализованы до степени отчуждения от разработчика [пред]проекта.

А вот слова
> дальнейшей тонкой настройкой макета
> и разработкой проектной документации.
действительно относятся к фазе проектирования.

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

Поддерживаю М.Горского:
> Я думаю, что мало кто из участников дискуссии готов отвечать
> за результаты перестройкы клиентского бизнеса.

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

By ppv on Вторник, Август 01, 2000 - 12:00:

Микаэлу,
Спасибо за доверие. Я подготовлю материалы о принципах и примерах открытой модели предприятия и вышлю их Вам на этой в начале следующей недели.
Александр

By ppv on Вторник, Август 01, 2000 - 12:00:

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

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

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

By Федор Петренко on Вторник, Август 01, 2000 - 12:00:

Тема предпроектного обследования действительно крайне животрепещущая.

В предыдущем обсуждении по-моему собеседники говорили как минимум о трех различных проектах:
1. Проект, в котором клиент точно знает, что он хочет от КИС, но не знает сколько на это уйдет времени и денег.
2. Проект, в котором клиент не знает точно, чего он хочет от КИС, но точно знает, что ему нужна именно КИС.
3. Проект, в котором клиент знает, что у него "все плохо", но не знает, что ему делать.

Отчасти (только отчасти), это объясняет разные точки зрения.

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

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

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

Вам плохо? - Да!
Я дантист! И сделаю Вам хорошо! - Я Вам почти верю!

Дантист начинает с предпроектного обследования и диагносцирует рак, инфаркт, перелом ноги и маленькую дырку в зубе. Что дальше делает дантист?
Вариант №1
Вам плохо на 1MUSD, предлагаю Вам обратиться к кардиологу (это будет стоить 500K), хирургу (300K), онкологу (290K) и собственно ко мне (10K).
Вариант №2
Вам плохо на 1MUSD, предлагаю обратиться ко мне.
Вариант №3
Вам плохо на 1MUSD, основная проблема - это дырка в зубе (990K), но также не забудьте про кардиолога, онколога и хирурга (10K на всех).

К сожалению варианты 2 и 3 встречаются на российиских просторах гораздо чаще, чем этого хотелось бы.

К вопросу об ответственности. Что происходит по окончании лечения? У больного все почти также плохо, он злобно спрашивает дантиста, почему мне все так же плохо, а довольный дантист говорит: но дырки в зубе то нет!

Итак предлагаю тему для обсуждения: Насколько уместно использование предпроектного обследования для продажи услуг по внедрению КИС.

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Беда в том, что кооперация "ДАНТИСТ- КАРДИОЛОГ" в нашем бизнесе очень слабенькая (читай автоматизаторы - "чисто" управленческие консультанты ).

By Мазуркин Сергей on Вторник, Август 01, 2000 - 12:00:

Олег, согласен с Вами.

Могу добавить. Считаю, что "кооперация ... слабенькая" не потому что скооперировать некому. Считаю, что и специалисты есть, и соответствующие структуры.

Скорее всего, клиенты не готовы к такой кооперации.

В терминах примера получается, что пациенты не приходят лечится. Они приходят лечить тот или иной орган.

Вопрос, наверное ко всему сообществу форумов. Каково Ваше мнение, почему нет такой кооперации?

By Александр Пыпин on Вторник, Август 01, 2000 - 12:00:

Коль вопрос ко всем, выскажу свое непрофессиональное мнение...
Прихожу я к терапевту с больным
животом. А живот - то у меня болит,
от гнилых зубов. Терапевт конечно
об этом знает - но если он пошлет меня
к дантисту, то соответственно деньги получит
не терапевт, а дантист. А зачем это терапевту надо ? Он лучше долго и мучительно
будет лечит "от живота".
Вот и нет кооперации.

By Микаэл Горский on Вторник, Август 01, 2000 - 12:00:

Александру - вам не везло с терапевтами. Профессионал мотивирован не только деньгами, но и качеством работы.

Федору - трех "различных проектов" не бывает. Мы, например, работает только со 2м случаем, все остальное - к терапевту из предыдущего сообщения. А роль обследования в маркетинговом процессе - трудно сказать, мы, опять же, собственно обследованиями и "торгуем". А для поставщиков/разработчиков - можно, конечно, и такой маркетинг проводить (и даже нас приглашать), но только ведь дорого очень...

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

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

Держим удар ?

By Федор Петренко on Вторник, Август 01, 2000 - 12:00:

Александру:
Проблема на самом деле знакомая и более чем типичная. Понятна и дилемма:
1. Очевидно, что хочется денег.
2. Менее очевидно, но суммарная емкость рынка консультационных услуг сокращается после того как компания встречается с "терапевтом-шарлатаном" - режутся бюджеты корпораций на внешних консультантов, появляется негатив в глазах собственника или руководителя при слове консалтинг. Особенно это касается молодых российских компаний (5-10 лет), которые в настоящее время вступили в период бурных реорганизаций, организаций холдингов и т.д. А ведь именно эти компании, а не западные будут определять (или уже определяют) рынок консалтинговых услуг.

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

Майклу:
Вы не выдаете желаемое за действительное, когда говорите, что работаете только с проектами типа 2? Бывали ли случаи, когда приходил клиент, который утверждал, что он типа 2, Вы диагносцировали тип 3 и отказывали клиенту в услугах?

By ppv on Вторник, Август 01, 2000 - 12:00:

Микаэл,
не понял я, ошибка какая-то, утверждение Ваше о терапевте и о денежной мотивации меня никак не касается:(
Давайте другое:)
Александр

By Александр Пыпин on Вторник, Август 01, 2000 - 12:00:

Майклу. Одно не отрицает другое. Терапевт
будет профессионально лечить "от живота"
и в итоге вылечит. Т.е. добьется
такого состояния, когда болезнь не
беспокоит клиента. Но истинная причина
и более легкий путь лечения так и остануться
неизвестными клиенту.
P.S. Лично к моему опыту приведенный
пример отношения не имеет.

VVP: Под Александром имелся ввиду я.

By Микаэл Горский on Вторник, Август 01, 2000 - 12:00:

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

Федору - к нам обычно приходят либо те, кто уже потратил $xx,000 на софт, и им надо, чтобы оно теперь работало, либо те, кто имеет утвержденный бюджет на ту же сумму и вменяемый short-list, по которому мы и работаем. Других - не то, чтобы не видали, но никогда не работали с такими.

Ал-ру Попову - я действительно не вам писал, а г-ну Пыпину.

Всем привет.

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Микаэлу - давайте разберемся , что такое "впаривать".
Впаривать - это по моему, продавать программу без гарантии решения проблем заказчика. Вы правы, так наверное работают многие франчайзинговые компании структуры 1С и им подобных.
Согласен с Вами, что идеальных и универсальных программ не бывает в принципе и мы действительно обречены продавать свой софт (фирмы-разработчика) и те технологии (со своими ограничениями), которые в нем заложены.
Одно но : серьезная компания в принципе не может впарить, потому-что в проектной документации честно и согласованно с заказчиком дается заключение по каждому требованию - решается/решается путем доработок/не решается.
Что касается софтового "магазина", то это очень красивая утопия типа коммунизма.

Я понимаю, какую схему вы имеете ввиду:
консультанты делают предпроект, затем формулируют перечень требований и подбирают (рекомендуют) некоторый софт, который худо-бедно подходит под сформулированные требования. Простите, а потом ?
Вариант 1. Вы отдаете все концы некоторой внедренческой компании
Вариант 2. Ваша компания самостоятельно настраивает, внедряет и сопровождает проект

По 2 варианту : возможен в случае создания холдинга(это Вы) типа "SAP-...BAAN-...Галактика-...Парус..."
По 1 варианту : более реальный вариант, но в этом случае Вы уже на какой-то стадии предпроекта должны плотно работать с внедренческой компанией и соответственно делится деньгами, иначе "внедрятели" будут повторно за Вами перепахивать клиента под свои технологии. А борьба технологий - это уже амбиции партнеров.

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Только сейчас сообразил, где у нас непонимание:
разработчик и внедренец серьезного софта - это одно лицо с региональными отделениями. Иначе не может быть.

By Федор Петренко on Вторник, Август 01, 2000 - 12:00:

Майклу:
Спасибо за интересный ответ и интересные идеи, мне кажется я Вас понял.

Олегу:
Мне кажется Ваш подход напоминает теорию Птолемея по сравнению с Коперником, в частности, после окончания мрачного средневековья он станет неактуальным.

А что касается разделения проектировщиков и установщиков, то это по-моему вполне реально. Заметьте, в строительстве архитектор не сможет забить ни одного гвоздя, но может сделать хороший проект, в последнее время все чаще в hard'e отдельно составляется ТЗ, отдельно приезжают дяди с дрелями и плоскогубцами и что-то сверлят, в софте вполне возможно то же, на самом деле я даже знаю конкретные примеры.

By ppv on Вторник, Август 01, 2000 - 12:00:

Насчёт разделения разработчиков от установщиков (строителей):
Хорошую тему вы обсуждаете, господа.
Разделение и создание кооперированной цепочки из независимых разработчиков и установщиков их продукции станет возможным после налаживания полноценного рабочего диалога между ними. После формального описания их общения. Установщики должны получить возможность влиять на решения разработчиков при проектировании ими новых продуктов. Идеально, если установщиками станут консультанты, а устанавливаемый продукт станет их инструментом проектирования организации и он же будет инструментом управленцев этого предприятия.
Это возможно и устройство этого инструмента можно обсуждать, сам инструмент есть и его можно потрогать.

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Хорошая аналогия с архитекторами !

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

By Александр Болдин on Вторник, Август 01, 2000 - 12:00:

Але! господа архитекторы-дантисты-терапевты. Мне кажется мы уклонились от очень интересной темы конфереции ;)
Что касается обследования (лично мне больше нравится термин "технологический аудит"), это вещь несомненно полезная для обеих сторон.
Поясняю. Мне часто приходится сталкиваться с тем, что на предприятии плохо контачат между собой отдельные службы. Главбух не любит начальника АСУ, начальник АСУ не любит главного конструктора и тп. Сами понимаете как это вредно для завода, вместо решения проблем происходит перекладывание ответственности (обычно крайним оказывается начальник АСУ). В этом случае наша задача - определить и показать руководству и менеджерам заказчика истинное состояние дел и пути (не способы, а именно пути) решения проблем.
Это кстати тоже тема для обсуждения - кто из менеджеров заказчика для консультанта самый заклятый друг?
Пардон, стараюсь быть кратким.

By ppv on Вторник, Август 01, 2000 - 12:00:

Уважаемый АБ,
Что это такое Вы обсуждаете интересное: любит - не любит...
Надо занять людей общим делом и для начала дать им язык делового общения (стандарты на термины, сленг) и чётко разделить между ними работу и ответственность (стандарты на документы, содержание работ, логическая схема работ, рабочие правила).
Без формального представления рабочей среды (т.е. без организации рабочего взаимодействия людей) этим же самым все занимаются при каждом рабочем контакте. Ищут общий язык. Можно и так, но накладно расходывать время и деньги на такую организацию дела.
Ну это совсем не по теме получается.
АЕ

By Микаэл Горский on Вторник, Август 01, 2000 - 12:00:

Г-ну Болдину - обследование не есть аудит ни в коем случае (на мой взгляд, естественно). Ибо аудит предполагает презумпцию наличия "правильного" способо ведения тех или иных аудитируемых дел (пожалуйста, давайте об этом не будем спорить - просто посмотрите International Auditing Standards). Когда же мы делаем предпроектное обследование автомобилестроительного холдинга на предмет внедрения ERP-системы мы понимаем, что не можем диктовать заказчику устройство его системы отчетности (или снабжения). Мы, скорее, должны у него выведать, как все на самом деле есть, аккуратно и структурировано изложить (сам он не может это сделать) и вместе с ним и с нашими знаниями о EPR-системах прикинуть, какие возможны пути внедрения с возможными рекомендациями по оптимизации. Так мы считаем и так мы работаем.
Олегу Смирнову - "впаривать" мною было использовано в качестве слова, подчеркивающего обреченность sales менеджеров и/или консультантов компании-разработчика усиленно продавать каждому заказчику систему. Вы не можете сказать клиенту - "браток, тебе наш П**** не подойдет - у него и этот модуль кривой и этот левый, а этот и вообще существует только на бумаге. Пойди лучше и купи 1С-Предприятие - оно и работает стабильней и стоит меньше и настроят тебе его франчайзеры 1С недорого и быстро. А для задач Б и Ц купи соотвествующий модуль Сан Системз - я слыхал, его кто-то на Мэри Кей внедрил так, что у них все летает и все счастливы". Так сказать сотрудник компании-разработчика не может под страхом увольнения и/или смерти. А значит - обречен впаривать свое произведение, выдавая его недоделанность за супер-настраиваемость ("это мы специально для вас допрограммируем")... Надеюсь, не обидел. По крайней мере, не хотел.
Еще по мелочи (перечитав ваши сообщения) - из указанных вами путей мы ходим иногда по второму (сами внедряем) и это требует не "холдинга", а просто прошедших обучение консультантов и цивильной поддержки со стороны разработчика. Иногда же мы комбинируем "первый" и "второй" вариант и выполняем часть работ по внедрению, деля их с консультантами разработчика. "Первый" вариант (отдача внедрения разработчику) нами никогда не рассматривался всерьез, да и заказчику весьма полезно, когда консультанты, знающие его как родного, остаются с ним и на внедрение системы.
Еще. Внедренец серьезной системы практически никогда не есть ее разработчик. Отсылаю к справочной литературе и зарубежному опыту. Да и сами мы не ТурбоБухгалтера внедряем...

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

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

О "независимости" некоторых консультантов.
После проведения предпроектного обследования консультантом , он должен решить некоторую матрицу по выбору софта и соответственно фирмы разработчика.
Вариант 1. Полностью софт Компании 1
Вариант 2. Софт компании 1 + софт компании 2 + софт компании N
(и на каждой задаче новые комбинации)

По любому варианту : да не может консультант дружить со всеми компаниями - разработчиками.
Почему ?
1 вариант. Не сложились финансовые отношения
2 вариант. Плохо разработчик работает с Заказчиком
3 вариант. Да просто привык консультант к одному-двум софтам (субъективные пристрастия)
4 вариант. Да нет у консультанта специалистов по этому софту.

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

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

>выдавая его недоделанность за супер-настраиваемость ("это мы специально для вас допрограммируем")...

А вот это удар по почкам. Уважаю точность.

By Пессимист. on Вторник, Август 01, 2000 - 12:00:

А имеет ли смысл обсуждать консультантов ...
Сколько индивидуумов имеют опыт работы более чем с одной системой?
Даже 6 и та обычно реально рассматривает не более 1-2 систем, с которыми знакома.

By Сергей Колесников on Вторник, Август 01, 2000 - 12:00:

Ну это слишком "пессимистично".

Сейчас многие уже имеют опыт работы с 2-3 продуктами, пусть и из разных классов (обычно ERP - финансы).

Но некоторые и больше. Я, например, имел дело ( в разной степени, естественно) более чем с 8 ERP и 4 более мелкими продуктами.

Так что реально набрать команду ...

By Федор Петренко on Вторник, Август 01, 2000 - 12:00:

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

By Сергей Колесников on Вторник, Август 01, 2000 - 12:00:

Уважаемые участники дискуссии !

Так как Федор Петренко предполагает сделать обзор проблематики Предпроектного обследования, то можно высылать ему материалы, предложения и пожелания по тематике дискуссии.

By Елена on Вторник, Август 01, 2000 - 12:00:

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

By Сергей Колесников on Вторник, Август 01, 2000 - 12:00:

Елена!

Отвечаю здесь Вам за два форума.
Опыт обьяснения заказчику что такое внедрение - конечно же есть. Этим только и занимаемся (занимаюсь :-)). Но Если продавец наобещал, то извините, заказчик требует то что ему обещали, и в этом он прав. Он то купил (точнее считал что купил) одно - а ему втюхивают за те же деньги - совсем другое. А платил то он как раз за "эффект кнопки", так что решать эту проблему надо не на уровне внедрения, а на уровне продаж.

Что касается "как есть" и "как будет" - это не к предпроектному обследованию.
ППО имеет довольно четкий формат, и такие разделы в нем не предусмотрены.

By Мазуркин Сергей on Вторник, Август 01, 2000 - 12:00:

Согласе с Сергеем.

Предварительное обследование вряд ли должно содержать раздел "как будет". Создание такого раздела - скорее всего другой вид работы.

Согласен, что один аспект проблемы - "втюхивание".

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

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

By ppv on Вторник, Август 01, 2000 - 12:00:

Все беды и споры вызваны одним обстоятельством. К проекту подходят как к одноразовому акту по схеме "убедил (уговорил, договорился), внедрил (продал)и отвалил". И часто это напоминает интеллектуальную проституцию: сделаем что попоросишь, как попросишь, лишь плати (всё равно кого целовать и куда целовать). Отсюда и применение терминов "втюхивание" и "паровозы".
Целью проекта должна быть не продажа услуг, софта и оборудования, а поддержка адаптивного развития предприятия со множеством циклов "генерация идей и альтернатив, обоснование критериев и выбора, разработка проекта и бюджета, организация и мотивация людей, контроль исполнения". Такие циклы есть самое дорогое. Их отсутствие или несовершенство и есть главная проблема.

By Сергей Колесников on Вторник, Август 01, 2000 - 12:00:

Александр!

Вам в известном вам форуме задали вполне конкретный вопрос: у вас что-то есть или только красивые слова.
Вы на него не ответили.
Следовательно ничего нет.
Тогда не мешайте обсуждать интересные вопросы.

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Сергею Колесникову : вы сказали, что ППО имеет четкий формат. Нельзя-ли поподробнее ?

By Елена on Вторник, Август 01, 2000 - 12:00:

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

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Устами женщины глаголет истина. Если заказчик собирается купить предпроект, то ППО по формату ему вполне будет достаточно. Если-же заказчик покупает в итоге ИС, то в ППО он должен видеть зачатки будущей системы.

Ничего, что я маслица в огонь ?

By Сергей Колесников on Вторник, Август 01, 2000 - 12:00:

Вот тут то и я подспел :-)
Формат предпроектного обследования примерно таков:
1. Цели проекта
2. Задачи, покрываемые проектом.
3. Функции, реализуемые в ходе проекта. Проблемы или наоборот бенефиты от реализации на новом уровне (от внедрения системы, например)
4. Изменения, которые должны последовать в ходе проекта. Особо должны быть указаны проблемные (или необходимые) изменения или те, которые связаны с проблемной реализацией функций.
5. Рекомендуемые изменения к стандартной схеме ведения проектов, специфичные для данного проекта и требующие принятия определенных решений, возможно по сравнению с уже принятой схемой.
6. Итоговая схема проекта (или нескольких следующих его этапов) с учетом всего предыдущего.

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

>Функции, реализуемые в ходе проекта. Проблемы или наоборот бенефиты от реализации на новом уровне (от внедрения системы, например)

От внедрения КАКОЙ системы ? Каждый софт обладает своими ограничениями и преимуществами.

>Особо должны быть указаны проблемные (или необходимые) изменения или те, которые связаны с проблемной реализацией функций.

А может в будущем выбранный софт не обладает свойством проблемной реализации функций ?
--------------------------------------------
Сергей, извините, если я не понял некоторой академичности Вашего шаблона. В связи с этим, нельзя-ли было живой пример под Ваш шаблон.
Уверен, что посетителям сайта будет крайне интересно. Я за конструктив.

By Сергей Колесников on Вторник, Август 01, 2000 - 12:00:

-От внедрения КАКОЙ системы ? Каждый софт обладает своими ограничениями и преимуществами.-
От той котрую собираются внедрять. Данный пункт имеет смысл в случае предпроектного обследования перед внедрением определенной системы.

- А может в будущем выбранный софт не обладает свойством проблемной реализации функций ? -
Ну и замечательно ...

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Тогда я не понял, за что меня пытались избить на этом форуме. Если софт выбран уже на стадии предпроекта.

> 6. Итоговая схема проекта (или нескольких следующих его этапов) с учетом всего предыдущего

А это тоже {Данный пункт имеет смысл в случае предпроектного обследования перед внедрением определенной системы} ?

Что тогда проект без привязки к конкретному софту?
Очередная груда бумаги ?

By Сергей Колесников on Вторник, Август 01, 2000 - 12:00:

Я всегда предлагаю сначала договориться о терминах ...
А то дальше получается "я ему про Фому, а он мне про Ерему".

Под термином ППО понимается обычно: Первый этап проекта внедрения.
Иногда оно проводится как самостоятельная работа, при этом не имеется в виду какой-то софт, а например "класс софта". Бывают и другие формы, но всегда должен быть на горизонте ПРОЕКТ, ПЕРЕД которым оно и проводится.

-Что тогда проект без привязки к конкретному софту?-
А действительно, что ?

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Well, договорились.

О терминах.Вы сказали:
>Что касается "как есть" и "как будет" - это не к предпроектному обследованию.

А к чему ? И в какой момент ?

>1. Цели проекта
>2. Задачи, покрываемые проектом.
>3. Функции, реализуемые в ходе проекта.

Как можно определить цели, задачи и функции, не построив модель "как есть" ?

>4. Изменения, которые должны последовать в ходе проекта. Особо должны быть указаны проблемные (или необходимые) изменения или те, которые связаны с проблемной реализацией функций.

Это-ли не концептуальная модель "как будет" ?

By Елена on Вторник, Август 01, 2000 - 12:00:

А ничего и не получится, заказчик будет недоволен отчетом по принципу "все мы рассказали, а вы деньги за это получли" и долго-го-го будет выбирать софт из предложеных 2-3 систем, перебирать

By Сергей Колесников on Вторник, Август 01, 2000 - 12:00:

Ну если о терминах, то:

А что такое "как есть" и "как будет"?

Я вообще не люблю эти термины. Они обманичиво понятны, но реально нефиксируемы.

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Сергей, не увиливайте от ответа: Вы сами их употребили ранее.

Моя формулировка устроит ?

Модель "как есть" - это комплекс бизнес-процессов, методов ведения учета, политики и т.д. существующий на обследуемом предприятии в данный момент времени.

Модель "как будет" - это ....все то-же самое... с учетом перестройки бизнеса (системы управления) и т.д.

Черт ! Тоже не люблю давать определения.

By ppv on Вторник, Август 01, 2000 - 12:00:

Колесникову.
Сергей, по-моему я высказался по-существу вопроса. Понимаю, если мои суждения верны, то внедрять станет почти нечего. Но мне нет дела до заработков производителей софта. Сколько трудодней нужно оплатить для "обследования" 1000 предприятий? А их живых больше 100 тысяч. А за "внедрение"?
Я уже приглашал Вас, Сергей, и вот в третий раз приглашаю к нам убедиться в наличии и снять непонятные мне подозрения.
Сергей, давайте не травлей заниматься, а обсуждать суть проблем и разбираться в идеях, принципах и реализациях идей, Искать новое и полезное. Мыслить креативно. Вы же можете, я знаю.

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

О концепции построения "открытой модели ИС".
Как и обещал Александр Попов, я получил на свой ящик описание концепции открытой модели.
Александр просил высказывать оценки, замечания.

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

В любом случае желаю парням удачи и не опускать руки.

By ppv on Вторник, Август 01, 2000 - 12:00:

Ситуация в российском консалтинге мне напоминает медицину. Традиционная медицина шельмует новое, чтобы не мешали зарабатывать. Аргументы подбираются, чтобы прикрыть обсуждение альтернативных путей и новых возможностей. Чтобы не обсуждать по-существу.
Кстати, на том "на одном формуме" я ответил и мой оппонент признал, что "идея классная". Любители жёлтенького могут получить удовлетворение. А мне интересно обсуждение нового подхода к проекту реформирования предприятий.

By ppv on Вторник, Август 01, 2000 - 12:00:

Спасибо, Олег.
Мы уступили невежеству и обстоятельствам, многое положив на кон. Мы уступили, но не проиграли и не смирились. Думаю время придёт.
Александр

By Алексей Важнов on Вторник, Август 01, 2000 - 12:00:

Господа,

поддерживаю Сергея Колесникова в предложении договориться о терминах. Он в статье "Как организовать проект внедрения" (есть на CRU в выпусках 66 и 67) прекрасно все изложил.

Сегодня я еще раз перечитал всю дискуссию. Хочется отметить ряд моментов, чтобы они не потерялись. Думаю, по ним имеет смысл поговорить в отдельных дискуссиях.

> Mikael Gorsky Пятница, Июнь 16, 2000 - 21:22:
>... после обследования вы предоставляете заказчику самому или вместе с вами
> принимать решение о выполнении проекта.
> ... груз ответственности за это решение сожет выдержать только заказчик.

Давайте конкретизируем роль и место заказчика в предпроекте. Заказчик ДОЛЖЕН активно участвовать в этой работе.

> Олег Смирнов Вторник, Июнь 27, 2000 - 10:54:
> Кооперации не получается из-за "бедности" клиента.
> ... Дело в том, что в проекте автоматизации компании, занимающейся автоматизацией уже присутствуют элементы управленческого консалтинга, а в проекте "чисто" управленческой компании не заложены элементы будущей автоматизации под конкретную систему.
> ... считаю, что будущее за компаниями, объединяющими оба этих процесса в единый проект.
Кто кого будет поглощать ? Автоматизаторы - консультантов, это - же очевидно.

> Микаэл Горский Пятница, Июнь 30, 2000 - 10:14:
> ... мы ходим иногда по второму (сами внедряем) и это требует не "холдинга",
> а просто прошедших обучение консультантов и цивильной поддержки со стороны разработчика.

Мне кажется, что основная беда российских систем - нет технологичного и ДОКУМЕНТИРОВАННОГО софта. Поэтому никто кроме разработчиков не в состоянии его внедрять :-(

> Микаэл Горский Пятница, Июнь 30, 2000 - 10:14:
> ... Внедренец серьезной системы практически никогда не есть ее разработчик.
> Отсылаю к справочной литературе и зарубежному опыту.

Согласен, мой собственный опыт привел к этому же.

Господа модераторы и авторы сообщений - может быть откроем новые дискусии, перетащив туда в качестве затравки указанные мной сообщения (и еще некоторые - готов написать по почте)?

By Алексей Важнов on Вторник, Август 01, 2000 - 12:00:

Олегу Смирнову.

Про применение методов искуственного интеллекта Вы написали
> Возможно время таких изобретений еще не пришло (но придет)

Я давно (со времени учебы в институте - 1981 г.) интересуюсь данным вопросом. Реально подобные методы применяются. Как правило - в системах на финансовом рынке. Самый больной вопрос - как уйти от "зацикливания" работы подобных систем и как состыковать такие системы с реальными фактами ФХД (с учетом).
Рекомендую посмотреть www.solvo.com. Они встроили ЭС в ядро системы управления складской логистикой. Сейчас один из российских заказчиков понимающий все плюсы от внедрения подобной системы (и, к его чести, не испугавшийся первого печального опыта работы с шарлатанами), пытается внедрить одну из разработок компании СОЛВО на своем складе промежуточного хранения (единица обработки - паллета). Я с интересом жду результатов проекта.

By Сергей Колесников on Вторник, Август 01, 2000 - 12:00:

Олегу Смирнову.

Я спрашивал не зря. Обычно под "как есть" etc. понимается модель, а не состояние. Например, я использую эти термины исключительно в этом смысле.

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

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Сергею Колесникову : справедлива-ли аналогия предпроекта-проекта с геометрической фигурой КОНУС ?
Поясню: если рассматривать начало проектных работ за вершину конуса, предпроект как некоторый усеченный конус, а собственно проект как нижняя часть конуса, где основанием является некоторый STOP или границы проекта.

By Сергей Колесников on Вторник, Август 01, 2000 - 12:00:

Честно сказать - аналогию не понял.
Так что отвечаю "как понял".

Нет, несправедлива!

Это скорее винт с переменным шагом.
На этапе ППО шаг самый крупный, постепено становясь все мельче и мельче.

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Хорошо, приведеду другую аналогию :

Можно-ли процесс идеального предпроектного обследования и последующего проектирования представить как процесс проявления фотографии - от контуров к деталям ?

By Сергей Колесников on Вторник, Август 01, 2000 - 12:00:

\процесс идеального предпроектного обследования и последующего проектирования представить как процесс проявления фотографии - от контуров к деталям \

1. Я бы все-таки сказал не проектирования, а выполнения проекта. Потому что если мы говорим о проектировании, то там все выглядит несколько по-другому ...

2. Если мы договорились о 1. то тогда аналогия хороша - так как на фотографии уже есть все изображение ...

3. А если речь идет по проектировании, то возможна аналогия с фотографированием, в том числе со всеми аспектами типа "резко-нерезко", "передержка-недодержка", "мыльница - профи" и т.д. :-)

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Сергей, вы явно занимались айкидо.

Хорошо, задам Вам вопрос напрямую: можно-ли представить процесс предпроектного обследования и последующего проектирования как единый процесс без четко обозначенных границ ? (см. КОНУС, фотография и т.д.)

By Сергей Колесников on Вторник, Август 01, 2000 - 12:00:

НЕЕЕЕЕЕТТТТТТТ ....

Как же можно управлять процессом "без четко обозначенный границ" ?

А ведь эти процессы очень сложны, и управлять ими надо очень четко.

By Сергей Колесников on Вторник, Август 01, 2000 - 12:00:

Мне очень понравилась аналогия с фотографией :-)

ППО - контрастное проявление
Пилот 1 - нормальное проявление
Пилот 2 - "мягкое проявление"

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Небольшая реплика.

>Мне кажется, что основная беда российских систем - нет технологичного и ДОКУМЕНТИРОВАННОГО софта. Поэтому никто кроме разработчиков не в состоянии его внедрять :-(

Если-бы проблема была только в этом.
Все здесь собравшиеся строят не просто ситемы автоматизации, а социальные системы.

Отношения между социумами, это вам господа , не протокол TCP/IP.

(рынок софта рано или поздно уподобится рынку харда, где производители - производят, а дилеры - торгуют, подбирая клиенту наилучшее решение из возможных.М. Горский)

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Слава богу, насчет фотографии договорились.

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

Описывая конус, я имел ввиду, что что многие консультанты идут по принципу построения геометрической фигуры "Мавзолей", когда выполняется предпроект (самостоятельный верхний блок) , а затем подбирается некоторый софт (нижний блок с трупом).

By Дмитрий Никулин on Вторник, Август 01, 2000 - 12:00:

Уважаемые господа!
Большое всем спасибо за активное участие в дискуссии.
Для более детального рассмотрения некоторых вопросов, затронутых в ходе обсуждения, по согласованию с авторами мы опубликуем в завтрашнем (11.07) выпуске статью Ф.Петренко "МЕТОДОЛОГИЯ: СОСТАВЛЕНИЕ ДИАГРАММ СОГЛАСНО ISO9000", а в 30 выпуске (25.07) статью А.Попова "ОТКРЫТАЯ МОДЕЛЬ ДЕЯТЕЛЬНОСТИ", упоминавшиеся в данной дискуссии.

Никулин Дмитрий, гл.редактор еженедельника CONSULTING.RU

By Микаэл Горский on Вторник, Август 01, 2000 - 12:00:

Господа,

Я сейчас буду готовить статью для Computer Reseller News / Enterprise Partner по мотивам этой дискуссии. Прошу тех, кто согласен, чтобы их высказывания были процитированы с указанием авторства, прислать мне по e-mail подтверджение и правильную подпись типа - Луи Герстнер (IBM Corp.).

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Микаэлу : Боюсь, что статья будет не совсем полной. В этой дискуссии мы не успели рассмотреть один очень важный вопрос:

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

Вопрос: Действительно-ли это так ? О каких масштабах перестройки бизнеса в нашей стране идет речь?

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

Или вопрос не ясен, или Микаэл распугал всех статьей...

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

By Микаэл Горский on Вторник, Август 01, 2000 - 12:00:

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

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

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

Действительно, если разграничить сферы компетенции:
1) совершенствование бизнеса
2) совершенствование управления бизнесом

то автоматизаторы никоим боком не касаются пункта 1. Что касается совершенствования управления бизнесом, то это прямая задача автоматизаторов, причем в этой области (не рассматривая узкопредметных знаний) в большинстве случаев вполне достаточно четкой логики и здравого смысла консультантов "от автоматизации".

By ppv on Вторник, Август 01, 2000 - 12:00:

Согласен с Микаэлом в том, что совершенствование бизнеса главное, а ИТ обеспечивает бизнес и его развития. Кроме того, ИТ всегда были и ныне являются частью бизнеса как способы общения людей (сигналы костра, письмена, телеграф, телефон, электронноя почта).
Но до сего дня в большинстве случаев это обмен между обладателями естественного интеллекта неструктурированной информацией в свободном формате. Обработку информации они делают на месте, выделяя из неё знания и факты. Вся сложность в свойствах языке общения. С убыстрением и усложнением содержания общения (content :) и с удалением общающихся надобность в структуризации информации и приведении её к едино понимаемым смыслам растёт.
В современном мире для общения в коллективной деятельности потребуется общий посредник, созданный на основе методов искусственного интеллекта, и стандарты наименования и представления данных и знаний. Это наверное со временем станет новой письменностью. Так что ИТ изменятся кардинально и очень скоро. Они будут развиваться в сторону поддержки коллективной деятельности.

By Александр Болдин on Вторник, Август 01, 2000 - 12:00:

Для ppv
Уважаемый АЕ.
Да. Да. Да. Часто бывает именно "любит-не любит". Такова суровая правда жизни. Все очень сильно завязано на неформальном уровне. Попробуйте найти правильную линию поведения, если нужно внедрять финансовый модель, а понимания между главбухом и начальником АСУ нет. Простого человеческого понимания.
Относительно "занять людей общим делом и т.д.":
1. Не понял - как это я "варяг" буду рулить в чужой организации. И кто мне это позволит?
2. По опыту работы в фирме сертифицированной по ISO 9001, могу сказать, что даже успешное внедрение стандарта качества не дает гарантии отсутствия неформальных связей.
Извините за задержку, был в командировке.
АБ

By Федор Петренко on Вторник, Август 01, 2000 - 12:00:

По поводу разделения совершенствования бизнеса и внедрения ИС.

Я полностью согласен с М. Горским. Но более того, я хотел бы усугубить общую формулировку примером.

Подчас, полный отказ от ИС (переход на бумажный документооборот и т.д.) может быть полезнее для бизнеса (прибыльность, рентабельность и т.д.), чем автоматизация.

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

Мне кажется , что утверждение
"совершенстование управления бизнесом - дело рук толковых автоматизаторов" не верно. Совершенствование управления бизнесом это комплекс - кадры (HR консалтинг), маркетинг, финансы, общее управление, что-то еще. Одним из необходимых для поддержания технологии управления ресурсом является отапливаемое помещение, другим ИС, третьим электрический ток и т.д.

Для ppv.

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

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

By Олег Смирнов on Вторник, Август 01, 2000 - 12:00:

>Совершенствование управления бизнесом это комплекс - кадры (HR консалтинг), маркетинг, финансы, общее управление, что-то еще. Одним из необходимых для поддержания технологии управления ресурсом является отапливаемое помещение, другим ИС, третьим электрический ток и т.д.

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

By Алексей Важнов on Вторник, Август 01, 2000 - 12:00:

Олег,

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

By ppv on Вторник, Август 01, 2000 - 12:00:

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

By snake on Четверг, Октябрь 05, 2000 - 11:56:

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

By Олег Смирнов on Понедельник, Октябрь 09, 2000 - 13:31:

Все о больном, все о больном. Хорошие консультанты, плохие автоматизаторы. Так чем-же плоха идея Консультантов-Автоматизаторов ? Будем ждать появления магазинного универсального софта "для любого консультатнта" ?

By snake on Понедельник, Октябрь 09, 2000 - 15:40:

Олегу .. Я наверное слишком увлекся в пылу критики. Оптимальный вариант совмещения консальтантов и автоматизаторов я вижу только в том случае, когда автоматизаторы ведут два... три качественно различных варианта КИС. Ну и количественно, (наверное больше с точки зрения снижения затрат для клиента) с десяток вариантов. В этом случае консультанта трудно обвинить в необъективности. При этом совершенно неважно кто при ком. Другой вариант совмещения - при фирме автоматизаторов создается группа обоснования эффективности и формирования оптимального варианта внедрения КИС. Но я больше сторонник первого варианта. Ну и конечно 100% универсальный софт исключен совершенно... Универсальный софт для консультанта исключен совершенно ...По роду работы консультант должен уметь работать не только во всех сферах бизнеса, начиная от идеи бизнеса, бухгалтерии, финансов и кончая реализацией продукции услуг. Он должен знать специфику основных отраслей, если хотите... У него может быть более или менее приемлимый софт, но универсального никогда... Но он должен знать "передний край" софта, КИС и т.д. Практически тоже самое для клиента. Только соотношение универсальной части и той части которую необходимо адаптировать может составлять примерно 80% и 20%. Для консультанта скорее наоборот.. Например, я в своей работе редко пользуюсь стандартными программами.. Это скорее на завершающем этапе..

By Олег Смирнов on Понедельник, Октябрь 09, 2000 - 17:05:

Хоть убейте, не пойму, как можно отдельно взятой консалтинговой компании прекрасно владеть несколькими софтами.Сколько не говори сладко, во рту халвы не будет. Покажите, кто смелый, ту консалтинговую компанию, которая прекрасно запустила САМА несколько софтов и так-же прекрасно ПОДДЕРЖИВАЕТ (и развивает ?) то что сделала. Не представляю, как выглядят эти умники. А может пригласят на экскурсию к своим клиентам ? Впрочем портрет такой универкампании уже у меня сложился - кусочек Concorda, бухгалтерия 1С, отсутствие горячей линии и лихорадочные поиски партнера(ов), которые будут разгребать все что наделано (в лучшем случае). Шум идет страшный, что Аксаптой владеет любая уважающая себя консалтинговая компания. На Софтуле IT Partners заявили, что только они и какой-то еще один партнер сможет качественно удовлетворить клиента. Вот например, Вы Snake, неужели Вы честно сможете удовлетворить клиента одинаково хорошо при различных комбинациях софта ? Конечно чертовски приятно быть калифом на час...

By Snake on Вторник, Октябрь 10, 2000 - 09:33:

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

By Олег Смирнов on Вторник, Октябрь 10, 2000 - 09:47:

Snake, я переехал из Aris сюда, это будет логичней.Посколько мы заговорили об анализе структуры затрат, хотелось-бы послушать мнение участников и Ваше о следующем: 1) Возможно-ли на производственном предприятии построить систему планирования (с дальнейшей автоматизацией понятно)с разделением затрат на постоянные и переменные. 2) При условии, что есть около 40 видов готовой продукции 3) При условии, что возможно разделение смешанных затрат на постоянную и переменную составляющие 4) При условии, что бухучет (данные для план-факт анализа) построен по принципу сбора прямых и косвенных затрат. Цель такого планирования- более качественное управление затратами, о формировании ассортиментной политики я пока молчу. Заранее спасибо.

By Snake on Вторник, Октябрь 10, 2000 - 10:10:

Олег. Если можно несколько дополнительных вопросов: 1. Предприятие обеспечивает весь цикл? Разработка, производство, реализация? 2.В какой степени можно разделить по продуктам производственную часть, я имею ввиду один производственный комплекс выпускает 40 продуктов или какие-то продукты имеют в этом смысле специфику, например, используются какие то цеха только для одного вида продукта.. 3.Система управления производством - функциональная, матричная, дивизиональная или какая еще? 4.Это новое предприятие, или из старой системы? А навскидку не имея перечисленной выше информации МОЖНО, но потребуется переработка структуры управления в некий аналог проектной с переводом формы в систему бизнес единиц. Тогда и ассортиментная проблема решится если не "автоматом", то при нормальных разработчиках КИС легко может быть реализована в виде программного продукта как приложения КИС. Но еще бухучет должен строиться по продуктам...

By Олег Смирнов on Вторник, Октябрь 10, 2000 - 10:25:

1.Предприятие обеспечивает весь цикл - закупка сырья-производство-реализация 2. Три основных передела, вся номенклатура движется по одному циклу 3.Система управления - функциональная 4. Предприятие из старой системы 5. Калькуляция полной себестоимости по продуктам строится в бухгалтерии старым способом - сортовыми калькуляциями Никакой дивизионной или проектной структуры не будет, непрерывное производство, никаких автономных ступеней нет. Вопрос мой конкретный - возможно-ли (и как)перевести предприятие на планирование по принципу деления затрат на постоянные и переменные (при том, что бухучет ведется по способу отнесения затрат) и что в итоге получится хорошего с точки зрения управления затратами.

By Олег Смирнов on Вторник, Октябрь 10, 2000 - 10:29:

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

By АБ on Вторник, Октябрь 10, 2000 - 10:32:

To snake. Вы конечно правы относительно консалтинговых компаний и пр. Но - в идеале. А пока, что, мы видим следующее - пара наших крупных фирм (не буду называть каких, догадайтесь сами) объединяются и на базе своих мощных "маркетинговых" возможностей начинают трамбовать сколько-нибудь крупных заказчиков по всей стране на приобретение их собственного софта 3-й свежести. Используя все приемы. И какой тут независимый консалтинг?___________________ АБ

By Snake on Вторник, Октябрь 10, 2000 - 10:33:

Еще раз...В упор эту проблему не решишь, не меняя управления, это и Вам головная боль, да я думаю и Вашему клиенту.. По опыту это одна из тех структур которая практически не знает цену того, что она пытается реализовать.. Настолько упущен контроль над продуктом. Понятно что и расстановка приоритетов по развитию продукта в таких условиях невозможна. В принципе я что бы предложил: 1.сформировать весь продуктовый ряд в несколько групп скажем 4...5 до 7 2.реформировать систему управления каждой группой в некий проект, программу (на Ваш выбор), таким образом что бы она охватывала весь цикл от разработки до реализации, 3. придать статус каждой группе бизнес - единицы, таким образом что бы она отвечала за эффективность продукта на рынке, для этого придать каждой группе функциональные структуры - финансы, экономику, то есть сделать из них мини компании, фирмы и т.д., 4.Тогда система управления предприятием будет решать только стратегические вопросы, а б/единицы текущие и среднесрочные (снижаются издержки управления) 5.Затраты по каждой бизнес единице будут формироваться под конкретные продукты и зная их продаже способность на рынке вы всегда сможете "отловить" тот момент когда спрос на продукт упадет и вовремя ликвидировать его или трансформировать 6.Зная опять таки отклик рынка на тот или иной продукт и его реальные затраты у руководства будет достаточно достоверная информация о целесообразности инвестирования в тот или иной вид продукта, (это к вопросу об ассортиментной политике) 7. А вопросы учета прямые, косвенные, постоянные, переменные уходят на второй план.... А в том чистом виде как есть будет просто большая морока, потому что насколько я понял Вам придется внедрять КИС отчасти входя в проблемы бухучета С уважением.... Может перенести обсуждение в новый чистый раздел

By Snake on Вторник, Октябрь 10, 2000 - 10:40:

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

By Snake on Вторник, Октябрь 10, 2000 - 10:48:

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

By Олег Смирнов on Вторник, Октябрь 10, 2000 - 10:56:

Snake, по-моему Вы все усложняете, я-же написал, что дивизионная структура на ткацком комбинате невозможна. Как Вы себе представляете-полуфабрикаты (пряжа) готовится сразу под все виды ткани, в ткацком цехе добавляется смесовая пряжа, т.е. часть станков ткет одну ткань, часть станков другую, в красильное отделение поступает ткань и краска, краска кончилась, погнали другой артикул. Как Вы разделите расходы на обслуживание станков по дивизионным подразделениям ? А электроэнергию ? Snake, Чампи здесь не прокатывает, согласитесь ? Вопрос-то мой вполне конкретный: что даст анализ структуры затрат по их поведению (постоянные. переменные), возможно-ли это ? Дело в том, что составить план прибылей в маржинальной форме мне представляется вполне реальным, но вот как собрать факт (прямые и косвенные затраты), потом превратить в постоянные и переменные, а потом раскидать по артикулам ?... Сталкивались с такой задачей ?

By Snake on Вторник, Октябрь 10, 2000 - 11:18:

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

By Олег Смирнов on Вторник, Октябрь 10, 2000 - 11:40:

Не понял, если Вы делали такую работу, приведите пример, как вы разделили людей по группам продуктов. Можно я помечтаю ? 1.1. Бухгалтер по материалам - Парусина 1.2. Бухгалтер по материалам - Брезент 2.1. Мастер по ремонту станков - ремонтирует только те станки и в том объеме, на котором производилась "Парусина" 2.2. Мастер по ремонту станков - ремонтирует только те станки и в том объеме, на котором производился "Брезент" ...При этом кто-то некий учитывает, как работал станок 3.3. Менеджер по сбыту "Парусины" 3.4. Менеджер по сбыту "Брезента" Попахивает клиникой, Вы не ощущаете ? Может я неправильно понял дивизионно-матричную структуру ?

By Snake on Вторник, Октябрь 10, 2000 - 12:09:

Олегу конечно же все зависит от доли прибыли или затрат, которая относится на тот или иной вид продукта, если у Вас фирма 50 на 50 выпускает парусину и брезент, то вы правы. В рамках тех условий которые Вы описали именно такой выход. мастер по ремонту станков это может быть такая же бизнес единица которая по определенной трансфертной цене обслуживает основные бизнес единицы.Почему нет?Менеджеры по сбыту? опять зависит от объемов производства, и если завод ориентирован на выпуск только парусины и брезента то конечно при солидных объемах сбыта должны быть и тот и другой . А потом в самом начале я уже говорил, что можно делать бизнес единицы и по группам продуктов .. А потом это не дивизионально матричная структура, а скорее проектно матричная.. Именно так, но опять все зависит от объемов производства. Если у фабрики объем производства 50... 60 тыс дол, то это извините ИЧП или кооп или еще как то .. И возиться с этим не стоит. Конечно делить на что - то там еще нет смысла..Эффект не окупит даже зарплаты консультанта. Относительно бухгалтеров, на сегодня по моему любой бухпрог поддерживает учет по меатериалам, если вы имеете в виду централизованую бухгалтерию. А что касается бизнес единиц то по стандартным положениям это головная боль руководителя бизнес единицы иметь такого буха или не иметь. Он должен доказать, что это ему выгодно перед руководством.. И потом какая часть бух должна быть учетная или отчетная. Да в составе каждого проекта есть полный набор функциональных возможностей требуемых ИСО. Но рук.бизнес единицы может заказывать услуги центрального аппарата, но это ему как понимаете обойдется в копеечку. Поэтому все опять определяется коммерческой выгодой, что выгодно руководителю бизнес единицы. Если ему выгодно нанять своего сотрудника того менеджера, бух-ра и т.д., или заказать такие услуги на стороне .. Только это должно быть выгодно и основной фирме в том числе...В случае принятия неправильного решения б/единица будет расформирована, как в реальной обстановке фирма.. И что самое главное в этом случае четкое перераспределение старой функциональной структуры на бизнес единицы... А вообще у меня складывается впечатление, что у Вас недостаточно проработано состояние вопроса.. Почитайте литературу, например, материалы Маккинзи в продаже она есть.. Хотя они больше дают теорию..., но общие представления они дают. ВАЗ по последним сведениям переходит на систему бизнес единиц А уж у них то производство, точно не ткацкое.... Если по новым источникам ничего не найдете, то раньше это называли хозрасчет, бригадный подряд и т.д. Это конечно тоже не в полном соотвествии, но тоже даст какую никакую информацию. С уважением...

By Олег Смирнов on Вторник, Октябрь 10, 2000 - 12:26:

Snaky - я просто продемонстрировал, что нельзя с фанатизмом напяливать передовые шаблоны человеческой мысли на все подряд. Вы увели дискуссию в сторону: даже с введением дивизионной структуры понятия постоянных и переменных расходов не исчезает. Собственно, мы все это время говорили о разном. Если приблизиться к Вашей позиции, то концепция моя (согласованная с Заказчиком) несколько иная - статья затрат-ответственный распорядитель-ЦФО- руководитель ЦФО. Заметьте, никакого деления по номенклатурному признаку, а эффект тот-же, что и в Ваших благих советах. При все при этом я не откажусь от маржинальных принципов.

By Snake on Среда, Октябрь 11, 2000 - 10:54:

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

By Олег Смирнов on Среда, Октябрь 11, 2000 - 16:45:

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

By Snake on Среда, Октябрь 11, 2000 - 17:27:

Ни в коем случае... Просто надо понимать, что Заказчик наверняка - человек отдавший этой фабрике приличный кусок жизни.. Даже если нет.. У них другая психология, это есть даже у менеджеров сверхинтеллектуальных производств (с кем я сейчас работаю). Это народ поглощенный своей работой и к сожалению мало обращающий внимание на внешний мир.. От этого они никуда не денутся.. Производство этого требует... И в общем то руководитель предприятия, использующий обширный опыт явление редкое.. Это показали результаты перехода на рынок - 3...4% смогли выжить... я не буду сейчас вдаваться в причины.. В основном, даже у моего теперешнего клиента потребности такие: при том что он отслеживает передовую тематику по нашим вопросам, ему нужна грубо говоря бумага - "РУКОВОДСТВО К ДЕЙСТВИЮ" он не имеет физически времени ломать голову о мою методу, инструмент (хотя в какой - то степени он меня ставит иногда в сложное положение) И поэтому постоянно возникает вопрос: ты как консультант дай мне веер решений моих проблем, а я ткну пальцем (конечно подумав) у него положение такое, работа такая.. А в общем был рад пообщаться Успехов

By Сергей Рубцов on Четверг, Ноябрь 09, 2000 - 15:23:

Олегу Смирнову Естественно, заказчик глупее консультанта... Иначе зачем такой бизнес, как консалтинг, нужен? Snakу Где вы сейчас найдете "человека, отдавшего ... фабрике приличный кусок жизни" да еще способного быть заказчиком? На мой взгляд, бизнес-консультант может получить работу только в следующих случаях: 1. Наличие свободных денег и возможность реализации "отката" заказчику от бизнес-консультанта 2. Наличие у заказчика комплекса неполноценности, связанного с нереализованными в юности инженерными амбициями 3. Присутсвие последствий применения метода НЛП к сознанию потенциального заказчика И наконец, разве не очевидно, что научные методы управления - это вещь в себe для 99,9(9)% отечественных и зарубежных менеджеров? Научный менеджмент - это развлечение высокообразованных интеллектуалов. Это как большой теннис или гольф, выбранные из всего множества игр, в которые играют менеджеры. Какие из всего этого выводы?... Если честно, то не знаю. Одно мне понятно, что на большую часть вопросов этого форума однозначных ответов нет и быть не может, пока мы не определимся с единым глоссарием. Например, можно начать с определения предприятия, как объекта управления... Я бы был счастлив, если бы все усилия бизнес-аналитиков направились именно на разработку стандартной модели предприятия, как целеустремленной системы. Только после этого можно обсуждать алгоритмы управления предприятием. С наилучшими пожеланиями

By Snake on Четверг, Ноябрь 09, 2000 - 15:51:

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

By Олег Смирнов on Четверг, Ноябрь 09, 2000 - 16:43:

Сергею Рубцову. У вас наверное сегодня скверное настроение, или нездоровится. Где это вы видели, чтобы консультант платил откат хозяину денег ? Мои клиенты - самодостаточные люди, лишенные описанных вами комплексов и методами НЛП я не владею. Тем не менее в моих услугах клиенты нуждаются. Что-то не срастается у вас... (...Я бы был счастлив, если бы все усилия бизнес-аналитиков направились именно на разработку стандартной модели предприятия, как целеустремленной системы...) Чтобы потом запустить в космос ?

By Александр Усов on Суббота, Ноябрь 11, 2000 - 23:25:

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

By VB on Понедельник, Январь 29, 2001 - 17:30:

Господа!
К сожалению, подключаюсь поздно. Но тем не менее...
По-моему, в ходе дискуссии вы изрядно отклонились от первоначальной цели дискуссии. И перешли к обсуждению взаимоотношений "заказчик-консультант".
Хотелось бы вернуться...

Позволю себе предположить следующее:
1) Совершенно согласен с тем, что заказчик не глупее консультанта. Он более-менее успешен в своем бизнесе - иначе откуда деньги на консультантов и ИС?). И он осознает (чувствует?), что у него что-нибудь не совсем так, как хотелось бы - а то зачем ему все эти хлопоты и траты?
Сам он данную проблему решить не может/не знает как. Вот и ищет решение на стороне.
2) По-моему, совершенно правильно говорят, что постановка цели/задачи/проблемы - половина решения. И заказчик зачастую (или мне просто так не везло? :)) сам не может сформулировать ни целей, ни задач. Он хочет КНОПКУ, которая решала бы его проблемы. Поэтому прежде всего необходимо понять - а чего все-же желается? В чем цель?
3) Даже если цели заказчику ясны, он может их сформулировать и донести до исполнителя (т.е. есть как бы понимание "как должно быть"- остается еще задача осознания консультантами того, "что есть". По-моему, предложить путь перехода из неопределенного "откуда-то" в конкретное состояние "куда" невозможно.
Для всего этого и нужен предпроект. И я полностью согласен с утвержением "Предпроект-это платное ознакомление Заказчика ... с тем, как работает его предприятие". Хотел бы только поправить, в статье С.Колесникова фраза звучит так: "платное ознакомление ... Консультанта с деятельностью предприятия". А это другой ракурс. И тоже верный.

А посколку при этом задействованы некие ресурсы исполнителя, то предпроект обязан быть платным.

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

С уважением.
PS. Спорить с утверждениями, что я упоминаю прописные истины - не буду. Заранее согласен.

By Олег Смирнов on Понедельник, Январь 29, 2001 - 19:01:

>остается еще задача осознания консультантами того, "что есть".
Зачастую осознанием "что есть" начинаются и заканчиваются многие проекты автоматизации.
Не потому, что "не могу сделать", а потому, что заговорили и заорганизовали.

By Олег Смирнов on Понедельник, Июнь 18, 2001 - 16:30:

и все-же я одного не понял:
- ППО автоматизатора - модель "как есть" клиента
- ТЗ автоматизатора - перечень требований к автоматизатору.

Куда (в какой этап и документ) засунуть бедному автоматизатору модель "как будет" ? И кто ему эту модель даст ?

By Andrew Marchenko on Вторник, Июнь 19, 2001 - 17:02:

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

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

By Олег Смирнов on Вторник, Июнь 19, 2001 - 19:43:

Андрей, ответьте на простой вопрос - кто построит для автоматизатора желанную модель "как будет", если :

1. Автоматизатору за это не платят,он не умеет и не должен этого делать
2. Заказчик не умеет тоже
4. Автоматизировать его надо

By Andrew Marchenko on Среда, Июнь 20, 2001 - 14:23:

Олег,

Видимо, я не совсем понял вопрос...

1. а) Не платят - тогда, по краткосрочной логике автоматизатора,он [автоматизатор] имеет право предложить свое видение проблемы, то есть пойти революционным путем. В долгосрочной перспективе есть риск (причем почти никтор не говорит об оценке рисков проекта, что есть чуть ли не краеугольный камень понятия проект), что Заказчик не будет доволен проектом. А это уже повлечет крайне негативные для автоматизатора выводы и последствия. б) не умеет - если автоматизатор не умеет проводить стадию предпроектного обследования, то возникает закономерный вопрос о его способности качественной и квалифицированной работы по проекту. Ведь предпроектное обследование нужно еще и для того, чтобы оценить риски "правильного выбора поставщика решения (автоматизатора)". в) не должен - если Заказчик говорит, что ему не нужно предпроектное обследование, то это означает, что данный риск он берет на себя. Автоматизатору остается зафиксировать данный факт и с чистой (по данному вопросу) совестью продолжать проект...
2. А вот этого Заказчик и не должен уметь. Если бы умел, то Автоматизатор превратился бы в простого исполнителя воли Заказчика...
3. Моя предыдущая реплика говорила о том, что революционный путь не подразумевает сохранения полезного наследия, в то время как эволюционный это подразумевает. И не было ни слова о том, что от проекта необходимо отказываться...

А модель "to be", что, кстати, можно переводить и "как будет" и "как надо" (а это уже "две большие разницы"), в данном контексте должен предлагать профессионал (автоматизатор), одобрять и акцептовать Заказчик (или через внутреннее согласие, или через экспертную оценку, или через внутреннюю экспертизу), а внедрять и эксплуатировать уже обе стороны с четко разведенными зонами ответственности.
Заказчика нужно воспитывать так же, как воспитывается рынок подобных услуг...

By Олег Смирнов on Среда, Июнь 20, 2001 - 15:13:

Андрей, я наверное действительно неточно выразился...

Автоматизатор не умеет, не должен, не платят [за построение модели "как будет"]
Где Вы видели обратное и у какого автоматизатора поднимется рука вычеркнуть из оргструктуры отдел лизальщиков конвертов ? :-)

By Andrew Marchenko on Среда, Июнь 20, 2001 - 17:15:

Олег,

Может вопрос в том, что Автоматизатор не всегда берет на себя смелость назвать белое белвым, а черное черным? Это, конечно, палка о двух концах, показывающая в каждом конкретном случае незрелость как Автоматизатора, так и Заказчика...
Если Заказчик заинтересован в результате (положительном и действительно заинтересован), то он мало того, что участвует во всех этапах проекта, в том числе ППО, но и требует от Автоматизатора "правильных" слов. Причем "правильные" это не те, которые нравятся заказчику, а те, которые объясняют Заказчику, доходчивым до Заказчика словами, "правильные" вещи... В некоторых случаях слова могут быть и очень правильными и непонятными для заказчика, но очень умными и Заказчик даже может с ними соглашаться (в силу очень большой заумности и других причин), но как я уже говорил, Заказчика надо воспитывать (обучать, холить, лелеять, проводить ликбез и пр.), а вот за это уже действительно никто не платит, это входит в COS (затраты на продажу). А вот за саму услугу (здесь, модель "to be") деньги нужно получать. Правильно воспитанный Заказчик это понимает и платит. Иначе есть возможность получить не то, что надо, а то что хочет Автоматизатор.. А как мы понимаем цели и задачи Автоматизатора и Заказчика совершенно разные...
А по поводу вычеркивания отдела лизальщиков конвертов: вычеркивать его может быть никто и не будет, а вот не включить в проект автоматизации, как "не подлежащий автоматизации в этом столетии" можно легко. А затем уже идут аргументы, почему он не включен в проект, а вот уже потом, руководство компании должно решать этот вопрос самостоятельно...

By Олег Смирнов on Среда, Июнь 20, 2001 - 19:28:

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

А покуда заказчик мне не платит за to be, поехал я выдавать черное за белое, для его-же блага (заказчика)

By Евгений on Среда, Июнь 20, 2001 - 21:16:

Олегу Смирнову:
>"...но вот как собрать факт (прямые и косвенные затраты), потом превратить в постоянные и переменные, а потом раскидать по артикулам ?..."

Возможно следующее решение (мы применяем такой метод при оценке фактической себестоимости изделий машиностроительных предприятий, относящихся к мелкосерийному производству):
1. На финальной стадии - на стадии изготовления отдельных детале-сборочных единиц составляется производственное расписание работ и формируются сменно-суточные задания на рабочие места.
2. С каждым рабочим местом связываются три показателя:
- стоимость станко-часа работы оборудования (бригады);
- стоимость станко-часа простоя оборудования;
- стоимость станко-часа технического обслуживания (ремонта) оборудования.
3. Анализ фактического графика выполнения сменно-суточных заданий позволяет по каждому рабочему месту указать:
- какое время рабочее место ожидало, пока на него не поступит данная партия деталей,
- сколько времени проводилась обработка партии,
- как долго проводился ремонт или профилактическое обслуживание рабочего места до начала обработки данной партии деталей.
4. Для каждой партии деталей суммируются полученные затраты по каждому рабочему месту в соответствии с производственным расписанием, тем самым, определяются фактические затраты на изготовление изделий (затраты раскидали по артикулам), которые включают все фактические накладные расходы и затраты электроэнергии. Добавив стоимость материалов, получаем фактическую себестоимость...
Затраты на содержание отдела лизальщиков конвертов следует учесть в стоимости стако-часа простоя оборудования: неработающий стакок все-равно требует ежемесячных затрат на амортизационные отчисления, освещение и отопление помещений ..., и, в частости, на содержание обеспечивающих служб.

By Andrew Marchenko on Четверг, Июнь 21, 2001 - 16:32:

Олегу,

Я попробую объяснить более грубо:
Если отдел лизальщиков конвертов "Не подлежит автоматизации в этом столетии", то это не значит, что через них не проходит бизнес-процесс, который в том числе требует лизания конвертов. Это означает, что автоматизировать данный процесс можно по-разному: от простой регистрации события вылизывания этого конверта (выражается нажиманием кнопочки, меняющей, например, статус данного процесса с состояния "вложено в конверт" на "вылизано", что, соответственно, отражается на бизнес-процессе, но не требует его автоматизации) до производства специальной механизированной линии с мокрыми языками и автоматической подачи конвертов...
Здесь имелось в виду именно "не подлежит автоматизации"... Ведь есть принцип значимости или существенности. Это все должно входить в проект в объеме, необходимом и достаточном, но не более того, для успешного завершения проекта. Именно завершения. Другой вопрос, что управление ожиданиями заказчика - это совершенно другая тема и понятия Customer Estimations и Quality Assurance очень тесно связаны между собой и лежат в основе проектного управления. И если подходить к проекту с этой стороны, то вопрос, вынесенный в начало темы, а именно, нужно ли предпроектное обследование, на мой взгляд, даже не имеет право на существование...

By Andrew Marchenko on Четверг, Июнь 21, 2001 - 16:43:

Олегу,

В дополнение...
Сожалею, забыл еще один нюанс...
Кажется, что я понял причины нашего расхождения в вопросе.
Кто такой автоматизатор? Если лицо (физическое или юридическое), задачей которого автоматизировать все равно что, то, мне кажется, что здесь есть принципиальная ошибка.
Автоматизация хаоса дает лишь хаос. Прежде чем приступать к автоматизации необходимо понять, а каковы объекты и субъекты автоматизации. Кстати, это опять один из вопросов ППО. Кто-то должен нести ответственность за начальное установление объема работ и их содержание. Что говорит теория управления проектами? Есть два различных понятия Product scope и Project scope. Один про продукт (здесь процесс автоматизации), другой про проект (здесь объем работ, необходимых на данном этапе, для признания данного этапа успешным). Эти два понятия четко разделены и между ними есть ясная граница.
То, что Вы говорите, на мой взгляд, есть подмена понятий. Когда мы говорим про отдел лизальщиков конвертов, то мы говорим про Product Scope, а когда мы говорим про процесс их автоматизации (то есть определяем объем проекта на данном этапе), то это уже Project Scope, так как от этого зависит объем выполняемых работ.
И если за Project Scope в большинстве случаев ответственен именно Автоматизатор, то за Product Scope, то есть за то каким быть выходному продукту, уже отвечает его Заказчик. И если Заказчик говорит, что лизальщики конвертов должны быть автоматизированы во чтобы то ни стало и, если повезет, еще и определит объем этой автоматизации, то Вам остается лишь включить эти работы в Project Scope и заниматься дальнейшей работой...

By Олег Смирнов on Четверг, Июнь 28, 2001 - 21:17:

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

А вот я с вами полностью согласен, это область исключительно Project Score. Ведь еще не перестали платить за лизунов.
Извините, пишу на коленке, потому кратко.