arahТак что все претензии по квалификации можно переформулировать в тезис "Оракл сам не умеет внедрять свой же OEBS".

Респект!!!!

DarlandНе стоит пытаться систму заточенную на GAAP/IAS пытаться приспособить для РСБУ!

Не заточена она под IAS/IFRS как и не заточена для того, что бы вести нормальный мультивалютный учет сразу в нескольких стандартах учета. OEBS все таки писалась под US GAAP. Писали ее с конца 80-х а в конце 90-х припудрили, объединили и продали, что бы и профинансировать разработку Fusion и сделать методологический задел для системы нового поколеня.
Лари хотел построить свою, новую ERP. Вот и скупил бизнес других компаний вместе с клиентской базой, методологией и специалистами. People soft например пишет теперь новый HR модуль для fusion и т.п.

Prince-1777А вообще - ERP это прэлесть. Сидишь в столице и видишь как в урюпинске косячат при постановке актива на учет. Можно позвонить директору и назвать ФИО исполнителя. Отчетик хочешь по заполнению ШР в разрезе часовых поясов - час работы программисту.
Как жаль, что не пошли по пути создания центра обработки данных в масштабе России (один сервер на все МРК) - и внедрять легче и затраты меньше. Только вот ребятам хотелось наоборот - сроки подлиннее, бабла побольше :)

Вряд ли это возможно при нынешней организации Связьинвеста. Война в 1997 за активы бывшего Министерства связи привело к тому, что Связьинвест стал похож на конфедерацию, а не на единый организм. От этого и проблемы. Все МРК де факто независимые. Все имеют свои разные взгляды. Поэтому инвестиционный рынок предполагает на 85%, что будет реструктуризация компании с превращением ее в единого супер - оператора в 2007г. Как отразиться это на проекте, который будут делать новый десант непонятно.

А так если бы Связьинвест был бы един – то скорее всего сначала сделали бы центральное МРК а потом тиражирование. Но при той модели компании было это невозможно.

Prince-1777А вот что важно - никто упорно не хочет делать пилотный проект. Я не знаю фамилию главного методолога, но однозначно - это неспроста. Всем ведь понятно, что стартовать внедрение одновременно в 7 МРК - более затратно и более рисковано. Все равно будут стартовать с июля синхронно. Не понимаю.

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

P.S. Сдается, мне что там многие прекрасно понимают, что пилотный проект лучше. А вот к чему приведет политика пока не знаю. То, что махом заменили команды это не есть хорошо. Никто из этой ситуации по крупному не выиграет. Придут люди, которые будут разбираться в чужой модели при наличии 50% о том, что происходило, а потом пойдет та же свистопляска, что и раньше.

Выход есть: Как минимум Связинтеку набрать специалистов со стороны заказчика которые обладали бы знаниями OEBS и предметных областей с большой практикой не только автоматизации но и работе в бизнес - консалтинге или непосредственно экономических областях. Этих людей поставить в качестве руководителей групп со стороны заказчика которые буду контролировать исполнителя. Естественно, что знание областей это как минимум знание РСБУ применительно к OEBS.
В это случае Связьинтек выстроит свою работу. А смена одной группы исполнителей на другую особо ничего не поменяет в результате. Исполнитель потом будет кивать на заказчика по неправильно поставленной задаче.
Скупиться на такие вещи не стоит, дешевле будет, реально дешевле.

Leshic
Про GMCS 5 копеек положу в копилку :)
ибо ходил туда на собеседование - в качестве общей развлекаловки на должжность функ арха :)
1. Руководитель консалтинговой практики принципиально против любых кастомов.
2. С кадрами судя ао всему у них очень плохо - очень активно собирали народ
3. Показалось что уровень консалтера не такой глобальный
Следовательно если внутри СИ не будет или новых денег или резких административных действий проект умрет :(

Улыбнуло! Реально улыбнуло!
Ну, раз вы все достаточно быстро поняли сами, значит из вас получиться неплохой функциональный архитектор -))).

Prince-1777
> Все МРК де факто независимые
Фигня. Дружненько подписывали договора и акты выполненных работ. И сейчас подпишут.


А ДСВ?)))
Если честно не зря реструктуризацию затевают. Сдается мне как раз потому, что они де-факто независимые и имеют разные составы аукционеров. Государству это не нужно в инфраструктуре министерства связи.

Он не методолог. Он - главный землекоп и будущий крайний. Методолог сидит где-то выше и запрещает пилотный проект. Потому что быстрое и успешное внедрение не соответствует обновленной цели проекта. Обновленная цель - между строк материалов УК.
По поводу построения МРК - ждем результатов. Я думаю - уже никто брыкаться не будет.

В данном вопросе я с вами соглашусь. Очередное строительство очередной башни находящейся с краю. Очередной посредник пришедший на место ОТ но с совсем с другими целями нанявший главного исполнителя в качестве «мяса» для будущего фарш-броска.

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


И в ваших данных словах есть немалая доля правды. Тол ко вы как то со злорадной подходите к данному вопросы. Создается впечатление, что есть у вас свои счеты с ОТ. А я подхожу к вопросу, что истину нужно сикать по середине, так как имею возможность выслушивать мнение и интерпретацию историю с двух сторон.
Постараюсь ответить на ваши вопросы двумя частями:
1. а) Насчет бюрократии согласен. Но нужно понимать, что изначально проект строился на основе 7 МРК которые создали ГЦК как бы снизу, а не с центра и платили бабки то же сами, а не управляющая компании. Поэтому и бюрократия была построена с ориентацией на требование заказчиков. ГЦК должен был принять задачи сразу 7 МРК, отчитаться перед ними и всех сразу удовлетворить. Естественно разумно было строить задачу с центра но тут ОТ вряд ли рядом стояло, все же Связьинвест это последствие той войны которая была в 1997 и пока эти последствия до сих пор не погасили.
b) Насчет RP считаю, что уважаемый Prince-1777 вам хорошо ответил. Думаю, что будущий проект уйдет в аналогичном направлении -).
c) Насчет того, что компания ОТ из железячной решила удариться в ИТ консалтинг это не нонсенс а нынешние тенденции рынка. Что бы продавать дорого железо нужны дорогие ERP проекты, что бы стать полноценным брендом нужно охватить всю сферу интеграции и стать полноценным системным интегратором. Не вижу ничего плохого в этом. Компьюлинк поступил точно так, же купив GMCS, Рстайл открыл так же свои направления по внедрению ERP и т.д.
d) В том, что бизнес-практика OEBS развивается с нуля не вижу ничего плохого. Многие через это прошли и проходят. Естественно, что те кто появился после Борласа, самого Оракла и Квазара в большинстве случаев так и делали. То, что нашли хорошего заказчика а потом начали набирать команду это правильно и выгодно. По такому же пути идут АБС. Да и GMCS поступило аналогично набрав основной состав после нахождения субподряда. ОТ в этом плане аналогично поступило. Пригласи на проект подрядчиков, среди которых был и Oracle. Начали создавать свою команду переманив состав спецов из Протека и потом нанимая людей из других компаний. Там были и профи (которые работали в Oracle внедряли немало лет OEBS в США и России) и пионеры. В принципе состав такой же как и во многих других командах претендующих на «лавры» открыток как и аналогичные методы.
f) Опять же ОТ поступили достаточно мудро. Проект по OEBS не прошел зря. Конечно удар смены политики и невыплата годовой работы по Связи была не слабым ударом по данной компании. Но она успешно выдержала удар. Если оборот компании в 2005 был 240мл.$ в 2006 оборот компании составил 230$ и это при учете долга по Связи 30 мл. $. Все это спасибо тому, что ОТ за последний год увеличило оборот на рынке по остальным областям автоматизации (не железа) на 70%. Неуспешным был только проект по Связи. А направлений автоматизации у ОТ появилось не мало. Тут многие OEBS – ники зря наехали. Все достаточно просто специалисты по OEBS смотрят на свой рынок и не смотрят на другие. А ОТ в это время создало несколько видов ПО ( в т.ч. и модули своей КИС) и успешно сотрудничает еще и с другими крупными производителями другого ПО. Да и клиенты не слабые и Роснефть, Сибнефть и т.п. Так, что ОТ во многом экзамен 2006 выдержала.
2. Связьинтек я упомянул, не понят вашей радости. То ли вы радовались, что ОТ плохо, то ли что Связьинвесту хорошо. Отвечу на второй вариант. Не вижу пока ничего хорошего.
Вот что хорошего в замене ОТ на ISG которая так же не занималась OEBS как и многим другим. Ну наняло ISG в субподряд главного исполнителя. Главный исполнитель побежал нанимать массу народа (в т.ч. и с этого же проекта) и уже нанимал порядка 70% от прежнего состава. И опять на будущие масштабы народа не хватает, так что по слухам еще возможно и наймет субподряд (хотя это слухи).

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

Что плохого: Первое на баки попало несколько больших консалтинговых компаний. Второе вместо, того что бы рассортировать старую команду взяли новую которой вникать и учиться полгода а потом возможно пойдут открытки 2 а возможно и нет. Но главное, что бы не было подхода типа раньше ОТ внедряло не по AIM а мы будем по AIM и сразу всем станет хорошо. Этим можно только развеселить. Дело не в AIM а в архитекторах и основных направляющих специалистах а точнее, что бы они были не технарями а методологами. Но я в это не верю, не вижу пока я этого.

Prince-1777Единственное отличие - раньше ОТ совмещали обе функции (внедрение и $), теперь эти функции разделились между GMCS и СИТ.

Меня единственная вещь интересует - позиция GMCS. Захотят ли, смогут ли они все-таки запустить систему ? Какая разница чьи $, ведь от единой учетной системы никому еще плохо не было. Проблема даже не в том, Как внедрять. Главное - чтобы было Что внедрять. Ждем обновленного списка расширений


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

Если интересно я напишу свой путь решения проблемы как и свое мнение на целесообразность перехода R3. Могу состряпать небольшой анализ).

Prince-1777Интересно.
PS.
Меня тоже покоробила ссылка на AIM. Неуместная распальцовка. В регионах все равно не знают что это такое. Даже если бы и знали - все равно будут подходить формально.

Отпишу предложения как раскидаю немного дела. Я как старый реинженерщик могу сказать, что AIM не поможет. Да и эта лабуда отличается только схемам в модернизированном IDEF3 нижнего уровня. Остальная текстовая документация как дизайны и т.п. аналогичное. Дело в не в технологии составления проектных бумажек – они все похоже а в том, что бы делали проект люди которые имеют нормальный опыт автоматизации и являются бизнес - консалтерами а не технарями которые не зная областей поют про управленческий учет и бизнес-практики западных компаний ( которые великий OEBS естественно несет миру) как шаманы произнося заклинания. Термины слышали, а вот о чем они до конца не понимают. Аналогично и AIM -))). Вами наверно его еще преподнесли как средство реинженеринга а не как метод внедрения приложений? Есть у меня такое подозрения. Хотя, что это просто метод внедрения БП заложено в самом его названии))).

Prince-1777Интересно.


Хорошо. Тогда сначала о выходе из ситуации, а потом о возможной смене ПО.

а). Возможные пути выхода:

1. Первое, что необходимо сделать, это SVT начать набирать собственную профессиональную команду. Сосредоточиться по началу на функциональном и техническом архитекторе, а так же на руководителях логистики и финансов. То есть первые 3 человека. Основные параметры: финансово экономическое образование, опыт работе в финансово – экономических областях, БК и только потом автоматизации. Люди должны иметь опыт работы в ERP и опыт в работе по предметным областям. Знание по OEBS должны быть в рамках своих модулей и как ложиться на них учет (знание всех галок в параметрах и т.п. не совсем обязательна, но стоит стремиться к лучшему). Потом набор руководителей подгрупп. Фокус на знание предметных областей и OEBS, опыт работы по предметным областям и по OEBS (тут уж лучше знание параметров модулей и т.п. знать получше).
Возможные проблемы: Проблемы появятся сразу, так как народ не ломается на этот проект. Многие понимают мутность ситуации и понимаю сколько это стоит. Но напротив многие же пошли несмотря ни на, что к исполнителю. Значит тот сыграл неплохо в финансовом плане. Так как SVT гос. компания, ей для сбора команды все же стоит либерализовать систему мотивации. Так как за такой гемор. нужно будет платить рыночные зарплаты. В этом случае шансы набрать команду будут.

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

3. Необходимо из существующей модели выбросить многие лишние вещи в РМС3 а РМС3 выбросить в РМС 4. Сейчас модель содержит массу БП которые никогда сразу все вместе не запускались и никогда даже организованный заказчик сразу организационно все не съест. Поэтому избавляемся от всякого треша взятого на грудь теми кто особо ERP никогда не запускал.
1. Бюджетирование и контроль лимитов.
2. Цепочки утверждения (смыл их запускать руководители отделов не будут сидеть за OEBS да и параллельная система утверждения по почте останется)
3. Планирование ДДС.
4. Проекты
5. Внутреннюю заявочную компанию
6. Пересмотр складской структуры с выбрасыванием мелочевки типа денежных документов и т.п.
7. Выбрасывание многой мелочевки которую можно вводить на уровне ГК.
Пересмотр нескольких областей как распределение затрат и поступления услуг и т.п.

4. По-моему уже понятно, что не опробованную модель смысла нет запускать сразу в 7 ВМС? Сразу скажу даже если она будет сделана нормально их в 7 сразу не запустят. Первое заказчик не съест зразу все, что сам пожелал. Организационно не съест. Второе не сможет запустить такие объемы сразу во всех филиалах и Дирекциях – не хватит ресурсов работников, ресурсов консультантов, организационных ресурсах. Те кто запускал ERP и особенно OEBS прекрасно это понимают.
Поэтому необходимо заморозить все ВМС кроме одного. В этом одном МРК назначит плотный проект в дирекции и филиале который находиться в центральном городе МРК (например Новосибирский филиал). Набранная команда ГЦК подготовив окончательную модель едет за несколько месяце до запуска готовить персонал, доводить до ума перед запуском модель проводить обучение и тестирование в виде деловой игры по смежным процессам (а не по отдельным БП). Потом запуск и опытная эксплуатация в результате которой модель и документация меняться на 30% (обычно так и происходит). Вот тут уже выходит более нормальная модель с более понятными инструкциями для пользователей.

5. Вот теперь можно начинать тиражирование. Но сначала одна особенность. SVT необходимо ГЦК сконцентрировать в своих руках. То есть ГЦК должен состоять из своих спецов. Далее идет автоматизации остальных филиалов Сибирьтелекома и 6 МРК. Тут нужны специалисты в большом количестве – как раз можно привлекать на субподряд разные компании.

Плюсы:
1. Проект становиться более реализуем и безопасен
2. Более дешевый вариант особенно на первых этапах
3. Предоставление промежуточных результатов (например, внедрение пилота).
4. В случае реструктуризации которая сильно возможна, сокращаются риски зря затраченных денег. В случае чего плотному проекту легче прижить реструктуризацию чем большому. А шанс реструктуризации большой http://www.skrin.ru/analytics/reviews/documents/svyazinvest_061214.pdf?2326FC4B7F574456A0A3008B8A1C4DDA

Минусы:
1. Во первых это не устроит главного исполнителя (который набрал под это кучу народу) и еще некоторых ребят (а им спешить нужно – но это все слухи) http://compromat.ru/main/reiman/isg.htm
2. Во вторых процесс долгий
3. В третьих сейчас и также нет трех вещей необходимых для внедрение ERP ( закончилось слияние, поделена власть, выстроена стратегия компании и финансовая модель) а если пойдет реструктуризация тут вообще будет не до проекта.

Про SAP напишу попозже

paul310to iscrafm: а это стандартный трюк: "внедренец" поднимает мега-проект, про который понимает, что шансов нормально сделать нет; структурирует договор таким образом, что ~80% бабла приходится на лицензии и написание глупых бумажек; нанимает тупоголовых дешевых детей на написание бумажек... В результате, когда дело доходит до, собственно, внедрения, "внедренцу" уже похрен: основной объем бабла он уже получил, косты минимальны, судебные перспективы у клиента небогатые... А репутация... Ее ж на хлеб не намажешь...

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

Prince-1777Имхо, без бюджетирования и планирования ДДС в ERP вообще нет никакого смысла. Это же основа управлненческого учета :) А внутренняя заявочная компания и проекты необходимы самому топ-менеджменту МРК, так как накачивание инвестиций - это основная их деятельность :) Ну нет у них ни производства ни торговли. Как же можно основную деятельность не автоматизировать ??? Можно выкинуть зарплату и налоговый учет, но тут бухи взвоют. Хотя - налоговый они и так не сделают на OEBS. Или дотянут проект до времени, когда наконец минфин отменит это чудовище.
В этом одном МРК назначит плотный проект в дирекции и филиале который находиться в центральном городе МРК (например Новосибирский филиал). Набранная команда ГЦК подготовив окончательную модель едет за несколько месяце до запуска готовить персонал, доводить до ума перед запуском модель проводить обучение и тестирование в виде деловой игры по смежным процессам (а не по отдельным БП). Потом запуск и опытная эксплуатация в результате которой модель и документация меняться на 30% (обычно так и происходит). Вот тут уже выходит более нормальная модель с более понятными инструкциями для пользователей.Говорят, Сибирь отказалась в жестой форме.

А в остальном - конечно согласен.

Ну не совсем бюджетирование и планирование ДДС это управленческий учет. И то и другое фактически является текущим финансовым планирование и с управленческим учетом пересекаются уже на этапе контроля и анализа. Это шаманят автоматизаторы называя такие вещи управленческим учетом (не понимая полного смысла автоматизируемой области) это не есть правильно. Если бюджетирование + управленческий учет ( в т.ч. инвестиционная оценка) + стратегическое планирование + разработка и реализации стратегии ( в т.ч BSC) + и т.п (типа АБС) = система управление предприятием ( в т.ч. контроллинг)
Все это вместе сразу не внедришь и крупные проекты сразу так не внедряются, Никто не говорит, что внедрять не нужно но нужно внедрять по частям. Сейчас имеет смысл ограничиться именно управленческим учетом (куда входит РСБК с управленческими разрезами данных СУУ+ МСФО который то же несет долю нужд управления) + Налоговым. Тем более, что CУУ выстроенная прайсами достаточно прогрессивная и ее также нужно будет внедрить (УУ в разрезе процессов а не только ЦЗ) привязав потом к ABC.
Дальше не только сам Связьинвест не сможет сразу проглотить при автоматизации бюджетирование, планирование ДДС и цепочки утверждения сразу этого не смогли сделать и другие компании гиганты, на которых внедрялось OEBS где бардака было поменьше и внедрение было с центра с последующем тиражированием. Внедрялось все по ступеням – что обезопасило проект.

Теперь приведу некоторые аргументы:
1. Бюджетирование – первое знаю на примере одного МРК, что в нем нет даже понимания внутри компании методологии контроля лимитов по бюджетам. То есть нет понимания до конца. Что не дает возможности подготовить даже задания для OEBS перед запуском а не только остаток лимитов по бюджетным счетам. Уверен полностью, что все МРК ели будет запуск в середине года вряд ли дадут остатки этих лимитов. И вряд ли четко выстроят систему изменения и контроля лимитов перед запуском OEBS им бы пока выстроить финансовую модель в совей компании а не браться ее автоматизировать. Чем и предлагаю заняться пока будет запускаться сам учет. Во когда учет запуститься и люди уже будут вводить более менее данные, тогда и стоит ставить задачу.
2. Проекты. Объясните пожалуйста зачем вам нужен этот модуль? Что вы хотите в нем увидеть? Лишний пул данных промежуток между главной книгой, кредиторами, осами, дебиторами, запасами, закупками. Зачем? Заведите один сегмент инвестиционных проектов и другой сегмент задач (будущих инвентарных объектов) и формируйте на них стоимость объекта, потом передавая через GL данные в Осы. Вот увидите как громко забьют все МРК на данный модуль, поняв что это ненужный дополнительный отросток который необходим тем компаниям которые работают со строительством профессионально (то есть основной вид деятельности). Он конечно понадобиться Оксам компании, но только через много лет после того как начнут работать МРК на OEBS. Не съест Связьинвест все это сразу. Как и не раскидает свои остатки МРК по своим многотысячным складам (Области – населенные пункты) в разрезе проектов. Хотя это тема для обсуждения.
3. Насчет внутренней заявочной компании то же пока рано. Не созрели и не созреете в ближайшие 1,5 года после запуска.
Первое, потому что политику цепочек утверждения и так не смогли сформулировать – значит ее нет и не созрели пока (тут нужен БК а не автоматизация пока).
Второе никто согласование в Лотусе не будет отрубать, значит, системы буду жить параллельно (если запуститься) а что скажет служба безопасности и менеджмент непонятно и вряд ли будет понятно в ближайшее время. Значит дублирование.
Третье вы наивно думаете, что менеджмент компании сядет за OEBS и будет караулить в сводке событий когда появятся документы к утверждению? Ну раз на других компаниях поменьше с постепенной автоматизации этого не было то и у вас пока не будет. Максимум после 1,5 – 3 месяцев со ступором отгрузки или оплаты по заказу (заявки) и ругани менеджмент посадит своих спецов это делать, а сами это буду делать по Лотусу.
Четвертое: Когда пойдет белиберда с заполнением справочника позиций, регистрации заявок, заказов и бесконечных ошибок и откатов ошибок, утверждающим первые 3-4 месяца придется только и сидеть и все это дело переутвержать и отслеживать))). В результате чего либо создадут левую цепочку либо вообще разрешат утверждать создающим.
Пятое – самое геморройное это когда по внутренним заказам в модуле OM начинают отгружать по внутрискладским операциям ТМЦ. Это песня. Оказывается по складской структуре необходимо вести параллельные справочники в ОМ, любая ошибка в заявках приводит к застреванию операций в интерфейсе и т.п. Одним словом этот стык очень не удобный и вряд ли его разгребут кладовщики при отгрузке со склада (а действий там 15 шагов) и вряд ли хватит консультантов приставить к каждому отгружающему. Не советовал бы вам с эти связываться. Выход есть очень простой – служебную на отгрузку через Лотус и выполнять перемещение с помощью модуля Запасы. Кстати заявки на приобретение я не предлагаю отменять. Так, что заявочную компанию делать можно но только уже не внутреннюю а внешнюю.
Одним словом не геморойтесь вы сейчас с цепочками. Сделайте либо одну цепочку на всех где утверждающий будет сидеть из службы проверки данных и проверять правильность заполнения документов либо вобще разрешите утверждать создающему. Все равно никто не отменит параллельного утверждения в Лотусе и никто не отпустить и не оплатит без параллельно подписанного бумажного носителя))).
Вывод: Вот сами и подумайте нужны вам сейчас эти области или достаточно запустить учет. Ведь не съедите все. Лучше внедрить базу а на нее потом вешать остальное. И результат покажете и проект не завалите.
А то получиться картина. Заполняется заказ на приобретение с ошибкой, бах и пошло:
1. Не можем заполнить заказ нет заведенных проектов.
2. Завели проекты но не можем утвердить заказ так как из Комшира в проекты не скинут инвестиционный бюджет (сработала старая орг. Проблема стык оказался за рамками проекта).
3. Завели инвестиционный бюджет в ручную Не можем утвердить - не закачали бюджетные остатки в GL.
4. Через 2 месяца разобрались с бюджетом (наконец придумали хоть какую методологию) но не можем утвердить, так как руководители отказались утверждать в OEBS у них нет времени.
5. После ругани ( прошел 1 месяц) договорились с руководителями, что за них будут утверждать из специалисты – заказ утвержден.
6. Происходит поступление и оказалось, что в заказе не такая цена как товарной накладно – откат и вся цепочка заново (а ошибок будет море).

Вывод: Нужно вам все это сразу? Или лучше пока учет. Иначе если через несколько месяцев гемора все это и заработает то только для галочки. Лучше пусть эволюция идет постепенно. С дисциплиной и постановкой задачи в Связьинвесте большие проблемы как и со стратегией (а еще грядет и реструктуризация) зачем наступать на грабли на которые наступили так же более организованные и слаженные компании?

iscrafm
цирк... вот так и внедряют недоERP... основные блоки выбрасываем, оставляем главную книгу и еще какую-нить мелочь... Ура ERP внедрили... А основное в Excel, Access и подножных системах...
Внедрятели..

Вы кстати, сколько проектов по ERP успешно внедрили? И сколько сразу с налета с Бюджетированием и системой документооборота за один запуск с нуля? Расскажите честно? И желательно правдивый пример с крупных проектов. И прежде чем тут разводить критику читать научитесь. Говорилось о том, что бы вывести в третий релиз.