В тему хочу рассказать про один из уже реализованных проектов на одном из наших предприятии - почему сделана ставка именно на самописку...

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

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

iscrafm GaryaСкажите, а конфликт-менеджмент тоже входит в функции архитектора?:)конечно. Когда ты проектируешь здание всегда заботишся о его стойкости к внешним воздействиям и актам вандализма. Мы же не о картонных коробках в парках говорим?Хотелось бы мне увидеть IT-шника, приказывающего директору предприяти холдинга... :) Я - начальник управления ИТ управляющей компании, но такого административного потенциала не имею. Более того, вижу явное нежелание некоторых руководителей, с существенно более высоким статусом решать вопросы, связанные с автоматизацией.

Вы описываете некий идеальный случай. Но на практике всё выглядит немножеско иначе... :)

0xy9enВам просто нужен был консалтинг, а не система.
А в целом с вами соглашусь, что для автоматизации бардака лучше подойдёт самописка.Не могу с Вами согласиться. Самописка закрыла некоторые проблемы на некоторое время, хотя не решила и изначально не могла решить целый комплекс других проблем. Нужно понимать логику топов. Они решают не все проблемы, а те, которые считают наиболее для себя существенными. Я не вижу в этом никакой трагедии. Топы - тоже живые люди. И в пространстве измерения деньги-время-кайф они пытаются получить экстремум по оси "кайф", который определяется личной системой ценностей конкретного топа. Если топ получит максимальную прибыль за 1 квартал, доведя за этот же квартал себя до инфаркта, я полагаю, такой результат не будет вписываться в его стратегические планы... :)

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

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

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

iscrafmво-вторых, под самопиской понимаете только то, что создано собственным IT подразделением предприятия. Я немного шире.. то что создано индивидуально для конкретного предприятия, возможно сторонней организацией. Я директор, он директор... мы просто договариваемся кто как и какие ситуации разруливает. А гибкость решения позволяет устранять конфиликты зя счет реализации приятных пользователям "фенечек". И все таки... система разрабатывается чтобы облегчить, а не усложнить процессы информационной поддержки, даже на этапе ввода информации.Ну, если так рассматривать, то вообще грани между самопиской и не-самопиской стираются. Visual Studio ведь тиражный продукт? Можно ли считать программы, в нем написанные, самописками? Или всего лишь настройками последовательностей байт под особенности конкретного зхакачика? :) Точно так же и со всеми продуктами, имеющим встроенный ЯВУ - то ли конкретная настройка самописка, то ли настройка тиражной системы. Где грань? Нет ее!.. :)

andbary GaryaДругой вопрос - стоимость... Я уже писал и тут писали, что дело не в текущей стоимости продукта, а в его неповоротливости и излишней сложности!Гхм... Неоднозначно это всё... Что такое "неповоротливость"? Имеет ли масштабируемость к этому термину отношение? Если да, то, скорее, наоборот, самописки, если они разрабатывались на определенные нагрузки, врядли потянут существенно более высокие. Ну, разве что, программист будет таким садомазохистом, что сразу создаст сервер приложений под кластер, хотя его это вроде бы никто и не просит.

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

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

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

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

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

Можно на этот же цикл посмотреть еще с одной стороны - влияние на орг.структуру предприятия. Развивающая модель на фазе "взлета" предполагает отсутствие четкой организационной структуры. Вторая фаза обычно требует жестко выстроенной иерархии . Иерархия сама по себе очень мало динамична. Она обладает малыми рисками в условиях не очень динамичной среды, потому что каждый человек в ней - это "винтик", выполняющий свои " функции ", которые обычно максимально формализуются. Систему выстраивают таким образом, чтобы она наименее всего зависела от персоналий. Любой винтик легко выбрасывается из системы и заменяется другим таким же винтиком, которому дают формализованной описание его функций. Креативные личности в такой системе рубятся (совершенно закономерно и правильно) - их либо заставляют силой превратиться в "тупые винтики", либо уйти в организацию другого типа . Такую монстрообразную структуру имеют все гиганты бизнеса - тот же IBM, Microsoft, Oracle, General Motors и др. Они уже достигли потолка своего полета (или летят где-то близко к нему), поэтому для них жесткая формализация всех бизнес-процессов - единственный метод прогресса. И если кто-то побывал в подобных структурах, они по себе очень хорошо прочувствовали жизнь "винтика" в иерархической системе... :) Так вот, в такой системе - без ERP - ну просто никак. А чтобы избежать излишней динамики, нужно гнать в три шеи всех современных Биллов Гейтсов ("взлетчиков"). Кстати, кто-нибудь заметил, как он разумненько ушел в сторону после взлетной фазы? :)

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

Всё сказанное - ПМСМ.

P.S. Для имеющих доступ в ЗПТ и интересующихся фазой взлета Галактики, заходите почитайте ... :)