Система ЭД и управления бизнес-процессами

Система ЭД и управления бизнес-процессами

Доброго всем времени суток.

Руководство предприятия озадачилось вопросом внедрения системы электронного документооборота. Почему-то на глаза ему попалось решение от PayDox (www.paydox.ru). Соответственно, нужны отзывы от людей, сталкивавшихся с этим продуктом.

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

Заранее спасибо, с уважением.

490
Комментарии (99)
  • 22 сентября 2010 в 20:06 • #
    Сергей Новиков

    Александр, добрый вечер!

    В вашей компании задача сформулирована как "внедрить систему электронного документооборота" или всё таки вы хотите повысить эффективность и управляемость бизнес-процессов компании?

    С уважением,

  • 22 сентября 2010 в 23:51 • #
    Александр Веровский

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

  • 23 сентября 2010 в 20:22 • #
    Сергей Новиков

    Александр это не то что одно другому мешает.. это может быть просто напросто большой ошибкой. Если конечно речь идет о 100% желании оптимизировать процессы компании, а не получит откаты от внедрения именно конкретной системы :)

    Идти ОТ заложенного функционала в систему нельзя. Особенно опасно не иметь ЧЕТКО сформулированных требований, которым должна удовлетворять система.
    Нужно идти именно от требований компании, бизнеса.

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

  • 23 сентября 2010 в 06:35 • #
    Александр Руднев

    Александр, добрый день.

    На сколько я понимаю, Ваше предприятие является структурой Росатома?

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

    Что касается внедрения СЭД, как и любой другой системы, то сначала надо определиться с вопросом - что мы хотим получить в итоге?

    Уже после этого выбирать СЭД.

    На счет PayDox, ничего серьезного сказать не могу. В рейтингах сравнения российских СЭД этой системы нет.

    Мой опыт и российская статистика говорит о следующих вариантах по СЭД:

    1. БОСС - Референт (Lotus) - лучший на рынке
    2. Company Media (Lotus) - серьезный конкурент

    3. DocsVision (Microsoft)
    4. Directum (Microsoft)

    И еще, любая СЭД должна внедряться сторонними консультантами - это закон успешности внедрения.

    Подробности расскажу Вам в частной беседе.

  • 23 сентября 2010 в 10:19 • #
    Александр Лещинский

    Тезка, извините, но вот с
    > любая СЭД должна внедряться сторонними консультантами - это закон успешности внедрения.

    не могу согласиться категорически (!!!). Развертывать доказательную базу надо?

  • 23 сентября 2010 в 10:50 • #
    Дмитрий Титов

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

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

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

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

    блин...а итог то все тот же самый)) сильный размах это плохо...а слабый это хорошо...и лучше если он идет от потребностей сотрудников)

  • 23 сентября 2010 в 11:05 • #
    Александр Лещинский

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

  • 23 сентября 2010 в 20:04 • #
    Кирилл Васильев

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

  • 24 сентября 2010 в 06:09 • #
    Павел Калистратов

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

  • 24 сентября 2010 в 19:00 • #
    Сергей Новиков

    Павел, свалить всё на персонал конечно очень удобно. Всегда во всем виноваты сотрудники!

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

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

    Систему нужно делать прежде всего для повышения производительности труда РЯДОВЫХ сотрудников, которые и создают в основном всю цепочку создания ценностей.
    А все хотят только КОНТРОЛИРОВАТЬ, в следствии чего большинство внедрений приводит к тому что повышается нагрузка на персонал. Да и данные всё равно в итоге собираются далеко не актуальные :)

    К сожалению часто люди работают на систему, а не система для них.

  • 26 сентября 2010 в 00:24 • #
    Кирилл Васильев

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

  • 27 сентября 2010 в 06:46 • #
    Павел Калистратов

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

  • 27 сентября 2010 в 16:20 • #
    Кирилл Васильев

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

  • 27 сентября 2010 в 22:56 • #
    Сергей Новиков

    Павел, есть хорошая крылатая фраза про консультантов..
    "Консультанты, это люди которые расставляют для вас дорожные знаки, но сами по этим дорогам не ходят." :)

    Значит говорите консультанты предлагают "успешные процессы"? Может вы тогда встречали у таких консультантов пункт в договоре оплата ПО РЕЗУЛЬТАТАМ проекта? Или процент от сэкономленных в результате оптимизации средств?
    Да впрочем статистика "успешных" внедрений различных систем говорит сама за себя.

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

  • 28 сентября 2010 в 05:26 • #
    Павел Калистратов

    Заказчик платит только за пилот. Остальные деньги по истечении двух месяцев работы с системой СЭД. Не всякий софт позволяет по такой модели внедрять,но есть варианты. Я не знаю,про какие системы с убогим интерфейсом вы говорите и неправильность данных, однако с талмудами инструкций тоже все просто - повер поинт или Опенофис импресс позволяет создать простые анимированые инструкции.

  • 28 сентября 2010 в 22:53 • #
    Сергей Новиков

    Павел, очень здорово платить ЗА ПИЛОТ и смотреть получится или нет. Удобно для вендоров и консультантов, но очень накладно для компаний!
    Интересно кто бы стал покупать машину как пилотный проект..? Заплатите, а потом посмотрите поедет или нет.. только у компаний бывает еще одна серьезная проблема, бизнес-процессы то приходится перестраивать и вернуться обратно бывает очень тяжело и затратно.

    Практически все системы, которые претендуют на "коробочно-подстроечный" вариант не имеют возможности заточки интерфейса под специфику деятельности конкретного сотрудника. Как итог удобство использования для пользователя отодвигается на второй план, а это влияет отнюдь не положительно на повышение эффективности в его деятельности.
    Видели когда-нибудь систему OEBs предлагаемую одним из ЛИДЕРОВ IT ранка..? удобство пользования и скорость работы там на высоте!

  • 29 сентября 2010 в 05:36 • #
    Павел Калистратов

    давайте посчитаем,не привязваясь к стоимости конкретных систем. Пилот ориентировочно стоит 10-20% от стоимости внедрения. Неправильно выбранный продукт несет за собой потери стоимость софта+стоимость внедрения. А между прочим,у автосалонов,аналогию с которыми вы привели,есть trade-in, чего,к сожалению,нет у продавцов ПО. Если честно,я не понимаю, о каком удобстве интерфейсов вы говорите.Есть стандартный интерфейс виндовс, есть стандарты в области юзабилити для веб-решений. Я не слышал от заказчиков серьезных претензий к неудобству интерфейсов СЭД. Что значит-заточка интерфейса под специфику деятельности и какую часть времени в проекте вы бы выделили на заточку интерфейса?

  • 29 сентября 2010 в 10:09 • #
    Кирилл Васильев

    А какой системы альтернатив OEBS лучше интерфейс?

  • 29 сентября 2010 в 20:47 • #
    Сергей Новиков

    Павел, ну Бог сним! Не поняли, будем считать что я не очень внятно объяснил. На форумах так бывает!

    На ваш вопрос могу ответить следующее 80% времени должно тратиться на подготовку и разработку ТЗ на систему, 20% на её реализацию и внедрение. Но ни как не на оборот.

    Очень хорошо что ваши заказчики довольны вашей системой!
    Искренне желаю вам дальнейших успехов!

  • 29 сентября 2010 в 20:50 • #
    Сергей Новиков

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

  • 29 сентября 2010 в 22:55 • #
    Кирилл Васильев

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

  • 30 сентября 2010 в 21:48 • #
    Сергей Новиков

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

  • 30 сентября 2010 в 23:49 • #
    Кирилл Васильев

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

  • 2 октября 2010 в 00:44 • #
    Сергей Новиков

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

  • 2 октября 2010 в 00:52 • #
    Кирилл Васильев

    Лично я на эту тему не заморачиваюсь, Заказчик строит самолеты, делает вкусные продукты, занимается розничной торговлей и это его бизнес, а мой бизнес внедрение, я не умею строить дома и если мне нужен дом я нанимаю строителей, если моему заказчику нужно внедрение, он нанимает внедренца. Каждый должен заниматься своим делом.
    Требовать от заказчика, что бы он научился разрабатывать документацию на внедрение, почему, зачем, мы же сервисом занимаемся, у нас не лавка самообслуживания.

  • 5 октября 2010 в 21:32 • #
    Сергей Новиков

    По моему мнению в этом как раз и заключается ключевая проблема непонимания IT и бизнеса.

    Кирилл, если никто не имеет представления КАК выглядит процесс разработки самолета, то как тогда можно создать качественный IT-инструмент - ИС для управления этим процессом?!
    Создать ПО для черчения нет проблем! Оно нужно. Но если мы хотим создать инструмент для УПРАВЛЕНИЯ, то не представляя себе процесс целиком этого сделать нельзя.

    Ну или можно, конечно, но тогда результат будет такой как есть сейчас :)

  • 5 октября 2010 в 21:49 • #
    Кирилл Васильев

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

  • 5 октября 2010 в 22:35 • #
    Сергей Новиков

    Не думаю что многие компании могут себе позволить платить за двадцать итераций :)
    А сейчас уже многие еще и 10 раз подумают насколько им нужны такие эксперименты :)

  • 6 октября 2010 в 02:06 • #
    Кирилл Васильев

    Это обычное разделение зон ответсвенности, услуги внедрения это:
    1. Консультирование и обучение.
    2. Программные доработки.
    3. Разработка документации.
    Внедрениец несет ответсвенность за качество этих услуг, заказчик несет ответсвенность за решения которые принимает, на основании полученных данных и документов. Если менеджеры заказчика не в состоянии принять решение, в бюджет включаются итерации, это нормально и более того, неизбежно.

  • 18 октября 2010 в 21:51 • #
    Сергей Новиков

    Кирилл, если внедренец берет на себя ответственность за то что в результате внедрения реально повысится управляемость и прозрачность процессов компании, то этого будет достаточно :)
    А нести оветсвенность за написание документации, обучение и доработку модулей ЗА "СЧЕТ" заказчика, это конечно хорошо!

  • 19 октября 2010 в 18:24 • #
    Кирилл Васильев

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

  • 23 октября 2010 в 01:45 • #
    Сергей Новиков

    Кирилл, на счет инструмента вы правы на все 100! Это действительно ИНСТРУМЕНТ!

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

    А обычно это выглядит так.. вот вам инструмент -
    молоток! А как нам деревья рубить?! А мы его сейчас заточим и всё будет хорошо! Ну и дальше понеслось.. :)

  • 25 октября 2010 в 12:16 • #
    Кирилл Васильев

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

  • 26 октября 2010 в 20:29 • #
    Сергей Новиков

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

  • 28 октября 2010 в 19:26 • #
    Кирилл Васильев

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

  • 28 октября 2010 в 20:44 • #
    Сергей Новиков

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

    Почему ничего нельзя сделать? Можно! Нужно менять психологию и взгляд владельцев компаний на эти вещи, честно им рассказывая что как и главное разъясняя почему. Мы потихоньку как раз этим и занимаемся.
    Но конечно это не легкий и не быстрый процесс.. Кризис к этому подтолкнул, вступление в ВТО то же не за горами. Так что стимулов двигаться к этому достаточно :)

    К стати, для маленьких и средних IT компаний в этом плане сейчас очень перспективное время.

  • 29 октября 2010 в 12:40 • #
    Кирилл Васильев

    Сергей, а попроще что-нибудь, можно придумать.
    Растить специалиста это хорошо, но долго.

  • 29 октября 2010 в 23:43 • #
    Сергей Новиков

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

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

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

  • 1 ноября 2010 в 16:55 • #
    Кирилл Васильев

    А как может консультант отвечать за результаты
    проекта?

  • 7 ноября 2010 в 23:20 • #
    Сергей Новиков

    Кирилл, раз консультант что-то обещает, то как-то нужно и отвечать за обещания :)
    ответил вам чуть "выше", а то тут как-то к сужению всё пошло..

  • 7 ноября 2010 в 23:26 • #
    Сергей Новиков

    Ответ по поводу вашего вопроса об оплате по результату.

    Варианты оплаты «по результатам» могут быть разные.
    Кстати, предложение компанией различных вариантов взаиморасчетов это одно из конкурентных преимуществ, но я немного попробую вам разъяснить.. :)

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

    Сразу определимся – речь идет о построении ИС для поддержки бизнеса выстраиваемого по методологии BPM. (В нашем случае мы понимаем BPM как методологию построения бизнеса, а не построения ИС).

    Пропуская этап презентаций и предварительных переговоров, сделаем допущение, что любой проект содержит следующие этапы:
    - утверждение целей, которые бизнес хочет достичь;
    - анализ бизнеса и его организации (компания, группа компаний, производство товара или услуг, продажа, товарно-рыночная схема, структура компании (ий));
    - общее представление бизнес-процессов (допустим: производства, управления производством, планирования и управления компанией);
    - описание БП выделенных для достижения поставленных целей;
    - *предложения по оптимизации (реинжиниринг) БП (определение выгод от реинжиниринга – пользы, которую получит бизнес от проведения этих работ (повышение производительности, повышение качества обслуживания клиентов, сокращение персонала, сокращение документооборота, повышение качества управления и т.д. - фактически экономическое обоснование);
    - предложение о том, как провести реинжиниринг (в том числе определение мест, где может быть полезно использование ИТ, вплоть до предложения какое ПО лучше использовать);
    (т.е., фактически, перечислен перечень работ этапа «консалтинг» - это не внедрение ПО)
    - принятие решения о необходимости изменения БП с использованием ИТ технологий…
    - определение стоимости работ по разработке или «внедрению» ПО

    Ну и т.д…

    В результате, вариант может быть:
    1. бизнесу предлагается проводить оплату работ по пунктам «консалтинг» по расценкам, которые не приносят прибыль компании ИТ (некоторые бесплатно, в качестве подарка :) );

    2. оговаривается стоимость разработки «внедрения» ПО
    оплата производится, например, так: 30% - оплата производства работ (тут уже лучше говорить о внедрении - включает разработку, установку и настройку) и 70% после подведения итогов достижения поставленных целей (м.б. разбита на завершение этапов) – стоимость определяется с учетом экономического обоснования см. выше*.

    Или П.2 может выглядеть как: 30% + выплата % от просчитанного экономического эффекта от «внедрения» проекта на протяжении.. времени. (м/использовано время окупаемости проекта для клиента)

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

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

  • 23 сентября 2010 в 12:24 • #
    Александр Руднев

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

  • 24 сентября 2010 в 12:23 • #
    Александр Лещинский

    А знаю еще меньше "варяжных". Так что кто что подтверждает - вопрос открытый

  • 23 сентября 2010 в 19:52 • #
    Кирилл Васильев

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

  • 24 сентября 2010 в 12:26 • #
    Александр Лещинский

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

  • 26 сентября 2010 в 00:02 • #
    Кирилл Васильев

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

  • 28 сентября 2010 в 05:29 • #
    Павел Калистратов

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

  • 23 сентября 2010 в 09:07 • #
    Дмитрий Титов

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

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

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

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

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

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

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

  • 23 сентября 2010 в 10:23 • #
    Александр Лещинский

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

    В тихие и мирные докризисные времена реально работающих проектов - 3-5% от начатых. Свежих цифр не имею

  • 23 сентября 2010 в 10:33 • #
    Дмитрий Титов

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

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

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

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

  • 23 сентября 2010 в 11:00 • #
    Александр Лещинский

    > поэтому имхо имеет своими силами или силами привлеченцев таки разбить задачу на мелкие кусочки со временем внедрения не больше месяца...два - крайний срок.
    Такие сроки - "это фантастика", да и имел возможность оценить весь фан от таких мелкорубленых процессов. То еще удуовольствие всем сторонам
    Agile-внедрение _сейчас_ мне кажется более реальным - и технически и финансово

  • 23 сентября 2010 в 11:15 • #
    Дмитрий Титов

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

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

  • 23 сентября 2010 в 20:40 • #
    Сергей Новиков

    Дмитрий,
    +1
    Хорошо написали со многим согласен!

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

  • 24 сентября 2010 в 06:17 • #
    Павел Калистратов

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

  • 24 сентября 2010 в 18:34 • #
    Сергей Новиков

    Павел, приветствую! :)
    Если у заказчика нет понимания того что ему нужно, то ничего хорошего из этого не получится. (речь не об интеграции систем).
    Консультанты внедренцев об этом ПОЧЕМУ ТО не говорят, тешат руководителей компаний тем, что вы наш продукт внедрите и у ВАС всё будет хорошо так как в него уже всё заложено - мы ваши бизнес-процессы "подгоним".. опс.. простите ПЕРЕСТРОИМ под систему! Только в результате такого подхода большинство проектов не изобилуют ПОЛОЖИТЕЛЬНЫМИ отзывами со стороны самих компаний!

    Многие из вендоров сами свою же предлагаемую систему внутри компании и не используют.. говорят что у них и так всё хорошо ;)

    К тому же создать на основе СЭД реально работающую систему управления очень проблематично.

  • 27 сентября 2010 в 06:52 • #
    Павел Калистратов

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

  • 27 сентября 2010 в 23:23 • #
    Сергей Новиков

    А кто сказал что нужно всё время ориентироваться на запад и делать так как говорят они?
    Вы считает они нам будут продавать передовые технологии? :)
    Западные системы свою эффективность показали..

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

    Судебные иски к вендорам говорят сами за себя по поводу "правильных процессов" и того что в итоге получили компании от внедреных систем :)

    А по поводу СЭД, этот функционал должен быть интегрирован (там где это нужно) в систему, а не быть отдельной системой, с которой нужно интегрировать другие системы (возможные исключения некоторые гос. ведомства).
    А иначе будет как у Аркадия Исааковича Райкина.. помните?
    К пуговицам претензии есть?! нет.. к рукавом? то же нет..
    только вот с кого спрашивать за то как функционирует система в целом непонятно.
    Может с IT директора? ;)
    Хотя в современных ERP системах чего только нет, модули для любого функционала есть.. да только что-то то же не срастается..
    Наверное ни как не найдут консультантов со знанием правильных процессов :)

  • 28 сентября 2010 в 05:19 • #
    Павел Калистратов

    Сергей, не нужно приписывать мне слова,которых я не говорил. А Райкин тут причем? Многим организациям совершеннно не нужно менять свои бизнес-процессы,ложась под "идеологию построения бизнеса BPM" и СЭД очень легко интегрируются. Однако консультант может и должен увидеть плохой процесс и предложить его улучшить. Навязывать заказчику СЭД BPM с перестройкой под идеологию системы-не лучший выход.

  • 28 сентября 2010 в 23:15 • #
    Сергей Новиков

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

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

    "Навязывать заказчику СЭД BPM с перестройкой под идеологию системы-не лучший выход"
    Павел, а где я говорил что нужно перестраивать БП компании под систему?
    Я говорил как раз о том что нужно понять и сформулировать требования которым должна УДОВЛЕТВОРЯТЬ система исходя из потребностей бизнеса, и только потом заниматься рассмотрением готовых решений или задуматься о собственной разработке.
    И BPMs и СЭД в нашем понимании две разные системы, хотя некоторый функционал который обычно понимают под СЭД в BPMs может входить, но он не является основой системы.

  • 29 сентября 2010 в 05:27 • #
    Павел Калистратов

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

  • 29 сентября 2010 в 10:19 • #
    Кирилл Васильев

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

  • 29 сентября 2010 в 20:41 • #
    Сергей Новиков

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

  • 29 сентября 2010 в 21:01 • #
    Сергей Новиков

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

    Стоимость внедрения увеличивает подход.. когда 20% времени проекта тратят на "обследование" компании и описание её БП, а 80% на внедрение. А все что свыше 100% далее тратят на бесконечные доработки системы, которым иногда не видно ни конца не края.

    Что вы подразумеваете под моделированием БП? Само по себе моделирование ради моделирования никому ненужно. Процессы описываются для решения какой-либо задачи (обычно задачи управления) иначе в этом смысла нет.

    Но вот серьезной ошибкой для компании будет описывать (моделировать) БП загоняя их описание в рамки возможностей какой либо системы, а не 100% ориентируясь на задачи бизнеса.

  • 29 сентября 2010 в 22:31 • #
    Кирилл Васильев

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

  • 30 сентября 2010 в 20:43 • #
    Сергей Новиков

    Кирилл, добрый вечер!

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

    Я считаю что автоматизация это ОДИН из способов оптимизации БП (и системы управления в компании в целом).
    Описывать БП для автоматизации на мой взгляд несколько неправильная формулировка.
    БП описывается (формализуется) для того что бы его прежде всего оптимизировать с точки зрения оптимальности и управляемости, исходя из специфики конкретного бизнеса и структуры компании (или холдинга) И С УЧЕТОМ ВОЗМОЖНОСТЕЙ современных IT (речь именно о информационных технологиях в широком смысле, а не о возможностях каких либо систем). IT в данном случае могут помочь в том что бы обеспечить поддержку БП и позволить повысить его управляемость в оперативном (и конечно стратегическом) режиме. Но в основном у всех проблемы именно с оперативным управлением, т.к. это очень короткие сроки за которые многое может поменяться, а управленческие решения нужно принимать, и без помощи IT в современном мире уже не обойтись.

    "С точки зрения автматизации, тут в принципе даже не особенно важны сами бизнес-процессы, скорее есть такой термин как информационные процессы, в таком процессе описываются не действия человека, а действия по его отражению в информационной системе."
    Кирилл, в любом процессе конечно есть ИНФОРМАЦИОННЫЕ потоки, но наш опыт показывает что описывать нужно именно БП (т.е. по другому деятельность), тогда получается учесть и все необходимые информационные потоки и ничего не пропустить.

    По поводу ИСО это вообще отдельная песня, не хочется затевать дискуссию на эту тему. Если вы этим интересовались то наверняка знаете как ИСО РЕАЛЬНО работает на практике. В основном работает как красивая бумажка.
    И к стати это не гарантирует, что потом каждый сотрудник будет работать так как написано в куче регламентов, которые разработали в ходе проекта по СМК :)

    Кирилл, спасибо за ваше предложение. Но у нас есть и методология и технология которая позволяет это все связать. Но пока к сожалению из-за текущих проектов не успеваем работать над проектом по её "обнародованию".

  • 30 сентября 2010 в 23:28 • #
    Кирилл Васильев

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

  • 2 октября 2010 в 00:22 • #
    Сергей Новиков

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

    На одном из "круглых столов" выступал представитель Сатурна (компания которая занимается выпуском двигателей для ракет).
    Он рассказал что проанализировав один из своих БП они пришли к выводу что нужно "поменять местами оборудование" (причем да же очень крупные установки, на перемещение которых они затратили не маленькие деньги). Это привело к сокращению времени выпуска некоторых изделий, сокращению простоя оборудования и т.п. Уже на этом этапе они получили серьезную оптимизацию процесса, за счет которой они очень быстро окупили вложенные в перетранспортировку средства . Вот такая вот оптимизация.
    А следующим шагом может быть внедрение какой-либо MES системы для АВТОМАТИЗАЦИИ производства. Это опять будет оптимизацией. Но как видите можно сокращать издержки компании и без внедрения систем.
    А иначе если процесс не оптимизировать, а автоматизировать то всем уже известно что будет - автоматизированный бардак :)

    К стати он рассказал что не одна готовая ERP система (они рассматривали разные варианты готовых систем) им не подошла т.к. не удовлетворяли их требованиям. В итоге они начали собственную разработку.

  • 2 октября 2010 в 00:31 • #
    Кирилл Васильев

    1. Спорить действительно смысла нет согласен.
    2. Что касается авиапрома там практически стандарт, это BAAN и подходит он почти всем от Боинга до ......, ну вобщем почти весь авиапром и большая часть Российского.
    Чтобы как-то прокоментировать это мнение я бы с удовольствием посмотрел их требования :-)

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

  • 5 октября 2010 в 22:32 • #
    Сергей Новиков

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

    Не помню как точно называлась статья, что-то связанное со "смертью ERP", у меня остались только некоторые высказывания Яна Баана из нее:

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

    «Перемены – враг ERP. Проблема классической ERP в том, что она становится как спагетти, если пытаешься ее изменить».

  • 6 октября 2010 в 02:22 • #
    Кирилл Васильев

    Боинг никому ничего показывать естесвенно не будет, кроме внедренной и работающей системы, на протяжении многих лет, боинг был основным референтным объектом БААНа.
    Ян ярый фанат Лари Эллисона, почитайте о нем, чего он только не говорил, Ян когда готовил БААН к банкротству тоже сказал не мало. Давайте ориентированться не на слова, а на дела, а по делу он создал очень приличную транзакционую систему, которая много лучше других работает с большими производсвенными проектами, за что ее так и полюбил авиапром.
    По поводу выской сложности ERP это так, есть такое дело, но и альтернатив нет. О высокой сложности корпоративных систем, маштаба предприятия, говорят давно и много, только альтернативы пока никто предложить не смог. И эти речи и БААН, и Эллисон старадали подобным, а на самом деле были направленны только на пугание конкурентов, что вот-вот и мы выпустим продукт который изменит мир и еще как пища журналистам чтобы им было о чем пофантазировать, а за одно и капитализацию объекту фантазий на бирже приподнять.
    Более того с каждым годом сложность систем только увеличивается, шлюзы между модулями упраздняются в угоду повышения оперативности данных, что вносит еще большую неразбриху.
    Заметьте раньше про ERP говорили как про набор модулей покрывающих функциональность, а сейчас как про набор функциональности, это связано с тем что модулей больше нет, гарницы между ними стерты, а современные системы не делимы.

  • 18 октября 2010 в 22:05 • #
    Сергей Новиков

    Кирилл, альтернатива есть всегда, было бы желание, а точнее заинтересованность тех, кто в компании занимается "внедрением" чего-либо в повышении эффективности работы компании, а не например в откатах от вендеров :)

    Что самое интересное, при изучении того как развивалась вычислительная техника и ПО можно увидеть, что изначально системы управления разрабатывались внутренними IT отделами крупных компаний (которые могли себе позволить компьютеры). Задачи программистам ставил бизнес и затачивалось всё под интересы конкретных компаний.
    С развитием вычислительной техники и её доступности, предприимчивые люди из IT поняли что можно "доработать модули" и создать систему для "ВСЕХ".
    В итоге появилось целое направление в бизнесе - внедрение (+ различного вида консалтинг).
    Но программисты не хотят углубляться в бизнес и понимать его так как это необходимо для создания эффективных систем. В итоге одну и ту же систему пытаются натянуть на всех.. итог тот который получили.. 10 лет уже говорят о том что бизнес и IT ни как не могут друг друга понять :)

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

  • 19 октября 2010 в 18:20 • #
    Кирилл Васильев

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

  • 23 октября 2010 в 01:40 • #
    Сергей Новиков

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

    Но обычно то идут от другого.. идут от готового ПО. И вот тут руководителей компаний начинают грузить, это нельзя, то нельзя. А ведь очень часто ЭТО НЕЛЬЗЯ в конкретной системе, это её ограничения. Но это не значит что этого реально нельзя сделать используя современные информационные технологии :)

  • 24 сентября 2010 в 09:28 • #
    Дмитрий Титов

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

    плюсы коробки - получать обновления...придуманные другими - совершенно даром - не ломая голову)

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

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

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

  • 24 сентября 2010 в 12:22 • #
    Александр Лещинский

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

  • 24 сентября 2010 в 18:39 • #
    Сергей Новиков

    +100!

  • 24 сентября 2010 в 18:46 • #
    Сергей Новиков

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

  • 27 сентября 2010 в 09:15 • #
    Дмитрий Титов

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

    в тех же случаях когда коробочное решение не подходит или его доработка слишком дорога и громоздка разумеется целесообразнее использовать разработку на заказ)

  • 27 сентября 2010 в 23:00 • #
    Сергей Новиков

    Не видел еще не одного коробочного решения системы для управления компанией, которое бы полностью удовлетворило владельцев компании ;)

  • 30 сентября 2010 в 23:40 • #
    Кирилл Васильев

    Это вопрос отношения к системе. На моем опыте я встречал, только три бизнеса под которые не ложатся коробочные решения.
    Кстати о коробках, можно с уверенностью утверждать, что все коробочные решения примерно одинаковы в одном классе, в большинстве случаев разработчики внимательно изучают решения конкурентов, копируя к себе функцинал. Разница только в нюнсах.
    А в целом, большинство коробок удовлетворяют потребность Закачика на 70-80 %%, за очень редким исключением. Причем, по опыту могу сказать, что при не совпадении, элементырных объяснений, почему так бывает достаточно, чтобы адекватный заказчик согласился изменить процессы и аналитики в сторону системы. Продиктовано это, тем что вендоры внимательно изучают результаты внедрений, и включают свои недоработки в план развития системы, не всегда это проходит быстро, но большинство систем развивается не один год и решения в них проверены практикой сотен, а в некоторых случаях сотнями тысяч компаний.
    Никакая индивидуальная разработка не даст такого качества и продуманности решения.

  • 2 октября 2010 в 00:34 • #
    Сергей Новиков

    Кирилл, почему тогда на западе проекты внедрений ERP систем считают успешными на 30-50%?
    Причем это среди крупных компаний.
    Да же если взять успешность за 50% (что в реальности под очень большим вопросом) то для владельцев компании это как подбрасывание монетки 50 на 50! И всего-то за пару млн. долларов :)

  • 2 октября 2010 в 00:44 • #
    Кирилл Васильев

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

  • 5 октября 2010 в 21:24 • #
    Сергей Новиков

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

  • 6 октября 2010 в 02:41 • #
    Кирилл Васильев

    Сергей извините меня улыбает такой вопрос как окупаемость ИТ. Она наверное есть, но как ее мерять и кто будет брать на себя ответсвенность за это.....
    Вот Вам реальный пример, внедрение системы управления городскими доставками с GPS, потрачено пол года, результат управляемость улучшилась, мы знаем, кто где и зачем, а время в пути увеличилось, ну не совершенные маршруты пока система прокладывает, все таки хороший водитель город и свои типовые маршруты проезжает быстрее доверяя своей интуиции. И еще расход бензина увеличился на 20%, связано с тем что, как выяснилось, система направляет туда где быстрее, так вот 0 км/ч для нее хуже чем 3 км/ч, а по расходу 10 минут постоять и потом поехать, лучше чем 20 минут ехать в пробке газ, тормоз.
    Причем систему прокладки маршрутов прогоняли на легковушке с водителем в течении недели, человек просто мотался, по заданым точкам, типа тестируя. Ничего подобного замечено не было, а вот когда в таком режиме поехало 60 газелей, через месяц всем все стало понятно.
    Смена оператора никаких позитивных резульатов не дала, у удного это так себе, другой карты редко обновляет, у другого инфа о пробках не всегда актуальна.......
    Но ведь в чем фишка, пока ты не попробуешь, не запустишь это в серьезном объеме инфрмации у операторов для усовершенствования своей деятельности не будет.

  • 18 октября 2010 в 22:21 • #
    Сергей Новиков

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

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

    Есть такой крупный игрок как УТКОНОС, наверное вы слышали. Они потратили огромные деньги что бы удержать бизнес на плаву. И сейчас в принципе можно говорить что они занимают хорошие позиции. Но очень большая беда для них, которую они не в силах побороть до сих пор, это как раз пробки.
    Пробки это проблема инфраструктуры + человеческий фактор. Мне кажется это не совсем корректный пример для сравнения его с системами управления для бизнеса.

    P.S. К стати сейчас уже начинают двигаться в сторону разработок ПО для навигации, которое будет учитывать ИСТОРИЮ пробок. Т.е. пробки как бы еще нет, но система будет знать что там она через 10-15 минут может быть и учитывать это при построении маршрута. Возможно это в чем-то поможет.
    Но вот когда стоит всё, тут конечно ни одна система не поможет :)

  • 19 октября 2010 в 18:14 • #
    Кирилл Васильев

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

  • 23 октября 2010 в 01:34 • #
    Сергей Новиков

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

  • 24 сентября 2010 в 06:05 • #
    Павел Калистратов

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

  • 24 сентября 2010 в 09:55 • #
    Виктор Левашов

    Можно много говорить про СЭД. Лучше всего начать пробовать с самого простого, с делопроизводства. Мы имеем очень простой продукт, называется АС "ДОК", кторый в небольшой организации можно установить и начать работать за 1 день, и потом развивать до требуемого функционала. Более подробная информация по запросу на #

  • 24 сентября 2010 в 18:50 • #
    Федор Глумов

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

    Но иногда бывают случаи, когда лучше заказать систему под ключ.

    Например, была такая задача. Есть множество филиалов, с которых нужно собирать отчетные данные и всех их объединить в общую систему статотчетности.

    1 вариант
    Можно организовать сбор через Excel файлы, поставить стандартную СЭД и работать с отчетностью через неё.

    2 вариант
    Можно взять систему, чтобы филиалы заполняли отчетные данные через web браузер (или грузили файлы из 1С) и все работали с общей отчетностью через Интернет:
    http://kaidev.ru/Pages/Olap/OlapETForm.aspx

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

    Во втором случае, точно можно учесть специфику и получить пользу, но есть риск так ничего и не внедрить, потому что разработка под ключ - всегда риск.

    Поэтому, сначала лучше по пунктам расписать, что должно быть, а потом искать систему, у которой есть максимальное количество этих пунктов в базовом варианте. Если >50% пунктов из списка нет в выбранной системе, то лучше рассмотреть вариант разработки под ключ.

  • 25 сентября 2010 в 19:50 • #
    Евгений Бялый

    Александр!
    Добрый день!
    Понимаю, что в любой структуре со сменой руководства меняется многое и новая метла по новому метет..
    Некоторое время назад мы внедряли решение EMC Documentum в Росатоме и планировалось, что это решение как и SAP будет стандартом. Возможно что-то поменялось. Ныне в свете Вашей задачи, готов предложить кроме EMC Documetum, решения на том же MS Sharepoint, хотя учитывая масштаб предприятия, остановился бы на ECM платформах. MS Sharepoint или IBM WeSphere предложил бы в качестве портальных решений. Ныне, есть также сильная BPM практика с опытом крупных внедрений, и возможно в свете большого "зоопарка" унаследуемых приложений это может быть оптимальным вариантом. Также, в свете решения подобных задач, у нас есть своя разработка хранилища данных с расчетом на работу до 20000 одновременно работающих пользователей. В сочетании с BPM получился отличный вариант решения. Также развиваем экспертизу по направлению OpenText и есть наработки по IBM FileNet
    Если говорить о PayDox - работаю на рынке документооборотных систем более 5 лет. Про проекты на базе этого решения слышал мало и предположу, что Вы являетесь не той компанией, которая хочет побывать в роли "кошки" для тренировки. Выбирайте сочетание промышленного решения - профессиональной проектной команды - полноценной поддержки партнеров и клиентов со стороны вендора в России и конечно опыта внедрений крупных распределенных проектов на базе предлагаемой платформы в России

  • 26 сентября 2010 в 01:03 • #
    Кирилл Васильев

    Прошу прощения не обратил внимания на название органзиации. Учитывая размер, я бы действительно предостерегся бы от использования мало известных решений, в 90% случаев данные решения не обкатаны на реально больших объемах данных и при большом количестве интенсивно работающих пользователей.
    К тому же клиент работающий на AJAX технологии, это тоже страшновато, технология пусть сейчас единсвенная кроссплатформенная, но все же пока ..........
    Как минимум для начала поросите у разработчика побывать на двух предприятиях, где они внедрились аналогичного вашему маштаба, поговорите с реальными пользователями, посмотрите систему в боевых условиях. Возможно остальные вопросы задавать и не придется.
    Если очень хочется с чего-то начать, а покупать дорогой софт не хочется, потестируйте 1С:Документооборот, это обойдется еще дешевле PayDocs и в целом могу сказать система хоть и очень молодая, ей еще года нет, но она реально работает.
    Там тоже есть кроссплатформенный AJAX клиент и виндовый тонкий клиент, кстати работает в разы лучше.
    Если есть вопросы по 1С:Документооборот, обращайтесь, у меня есть первое реально работающее внедрение, сейчас идет второй проект.

  • 27 сентября 2010 в 07:04 • #
    Павел Калистратов

    ну что вы так про 1С:Документооборот.
    Первое решение от партнеров на 1С было еще во времена царствия седьмой версии )))

  • 27 сентября 2010 в 11:10 • #
    Кирилл Васильев

    Вы по поводу возраста системы? Если да, то это факт http://www.1c.ru/news/info.jsp?id=11227, конкретная реализация совсем молодая.

  • 27 сентября 2010 в 07:00 • #
    Павел Калистратов

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

  • 27 сентября 2010 в 07:05 • #
    Павел Калистратов

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

  • 7 октября 2010 в 15:59 • #
    Олесь Панасенко

    Мы Докпрофом пользуемся уже более 3 лет. Более 400 рабочих мест, крупнейшее внедрение в Украине.

  • 29 октября 2010 в 09:48 • #
    Евгений Бялый

    Александр!
    Доброе время суток!
    Получилось ли у Вас на фоне развивающейся дискуссии определиться с выбором? Стало ли больше понимания или наоборот - большой выбор, дал еще большее количество вопросов?