in-house change management application

[Sabina]

Если кто работал(ет) над подробным проектом, не могли бы вы поделиться какими технологиями пользовались, сколько заняло по времени, оправдывало ли писать in-house product, а не покупать готовый.

Чем то, что вы написали отличается от того, что предлагается на продажу? Более ли оно сложное ( в смысле чего-то очень нужно именно вашей фирме там не было) или более простое (всех фич вашей фирме не надо было)?

Спасибо,
Cабина

[verzlo]

Если кто работал(ет) над подробным проектом, не могли бы вы поделиться какими технологиями пользовались, сколько заняло по времени, оправдывало ли писать in-house product, а не покупать готовый.

Чем то, что вы написали отличается от того, что предлагается на продажу? Более ли оно сложное ( в смысле чего-то очень нужно именно вашей фирме там не было) или более простое (всех фич вашей фирме не надо было)?

Спасибо,
Cабина

У нас все начиналось с in-house проекта написанного местной группой, и изначально требования были минимальными (разве что кол-во транзакций было изначально приличное). Ессно. потом было несколько фаз улучшения (добавлений модулей) и различных дополнительных условий и все время продукт очень медленно развивался (программеры не успевали) и в конечном счете бюджет на разработку почти сравнялся со стоимостью аналогичного уже готового продукта, который продвигали местные сейлзы из CA (Unicenter Service Desk)... И в конце-концов все купили (с приличной скидкой) и пользуемся. Пока нравится (лучше чем ихняя предыдущая версия). А часть тех людей перешла в администраторы этой системы

Все зависит от конкретных требований и возможности будущего использования (количество тикетов и кол-ва различных вариаций, различных групп, которые в этом учавствуют)..
ИМХО, для средних/больших change management systems в какой-то момент наступает тот порог, когда затраты на содержиние и суппорт in-house system сравняются или превысят затраты на уже готовый продукт..

[Sabina]

ИМХО, для средних/больших change management systems в какой-то момент наступает тот порог, когда затраты на содержиние и суппорт in-house system сравняются или превысят затраты на уже готовый продукт..

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

Сабина

[verzlo]

Начиналось все с локального change control для нужд Server Solutions and DBMS groups (about 500 users) для трекинга changes and problems on server's environments.
Затем, все это сталдо расти , подключались дополнительные группы из Voice Departments, Network, Security, Development Dept, etc.
Подключались дополнительные functionalities (different group settings, voiceOIP tickets generation, problems categorisations, automatic e-mail/paging notification of change/problem against your registered group/resource, extended reporting ).
Сейчас продакшн расчитан на 10000 конкурентных пользователей...

[Бродяга]

У меня в компании пытались написать свою. Угрохали 2 года, кучу денег. В результате получили глюкавого монстрика. Плюнули и купили нормальный

[Sabina]

У меня в компании пытались написать свою. Угрохали 2 года, кучу денег. В результате получили глюкавого монстрика. Плюнули и купили нормальный

Есть такое мнение, что многие подходят к change management излишне серьезно: теория Коламбо-Моламбо и проч. А если в компании инструкций по этому поводу один листочек и все упрощено? Глюкавые монстрики наверное получаются от попыток угнаться за сложными теориями и моделями?

Сабина

[zhitkoff]

У меня в компании пытались написать свою. Угрохали 2 года, кучу денег. В результате получили глюкавого монстрика. Плюнули и купили нормальный

Есть такое мнение, что многие подходят к change management излишне серьезно: теория Коламбо-Моламбо и проч. А если в компании инструкций по этому поводу один листочек и все упрощено? Глюкавые монстрики наверное получаются от попыток угнаться за сложными теориями и моделями?

Сабина

Наверное "масштаба" не хватает
У нас разработали свою собственную ин-хауз, веб-интерфейс, куча наворотов, но как обычно чего-то да не хватает ... Новые версии выходят потихоньку - становится значительно лучше, хотя надо признать, что старая система на мейнфреймах с кошмарно недружественным интерфейсом терминала 3270 была по внутренней функциональности круче на порядок ... Но ничего, догоняют потихоньку.
Моё ИМХО - если компания небольшая и не может себе позволить содержать _постоянный_ выделенный штат программеров (как минимум человека 2-3 + менеджер, ну куда-ж без него-то ) по разработке и поддержке собственной системы - то лучше купить готовое. Ну а если компания толстенная, да ещё и в сфере ИТ - ну тут сам бог велел своё делать.

[verzlo]

У меня в компании пытались написать свою. Угрохали 2 года, кучу денег. В результате получили глюкавого монстрика. Плюнули и купили нормальный

Есть такое мнение, что многие подходят к change management излишне серьезно: теория Коламбо-Моламбо и проч. А если в компании инструкций по этому поводу один листочек и все упрощено? Глюкавые монстрики наверное получаются от попыток угнаться за сложными теориями и моделями?

Сабина

Наверное "масштаба" не хватает
У нас разработали свою собственную ин-хауз, веб-интерфейс, куча наворотов, но как обычно чего-то да не хватает ... Новые версии выходят потихоньку - становится значительно лучше, хотя надо признать, что старая система на мейнфреймах с кошмарно недружественным интерфейсом терминала 3270 была по внутренней функциональности круче на порядок ... Но ничего, догоняют потихоньку.
Моё ИМХО - если компания небольшая и не может себе позволить содержать _постоянный_ выделенный штат программеров (как минимум человека 2-3 + менеджер, ну куда-ж без него-то ) по разработке и поддержке собственной системы - то лучше купить готовое. Ну а если компания толстенная, да ещё и в сфере ИТ - ну тут сам бог велел своё делать.

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

ИМХО, все дело в типах систем: те системы (программные продукты), которые непосредственно учавствуют в бизнесе компании (или делаются на продажу ) должны делаться in-house...
А Системы,которые предназначены для support и т.д. предпочтительнее покупать готовыми и настраивать...