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

Всем доброго дня!

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

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

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

Как с ними бороться. Найдите толкового PM. Он должен контролировать работу со стороны заказчика. Начиная от анализа плана проекта, и заканчивая выполнением пунктов этого плана, пинать ихнего PM-а, а никак не несчастных прогов, что очень часто практикуется. Разбейте проект на этапы. В ТЗ должны быть четко прописаны критерии завершения проекта и критерии сдачи, постарайтесь не спутать одно с другим.

Удачи вам всем.

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

Кратко о системе.

MASTER ENTERPRISE - самая настоящая трехзвенная система. С полноценным сервером приложений. Методы могут выполнятся как на клиенте так и на сервере. DCOM был выбран как наиболее подходящий вариант для работы с сервером приложений из других систем. Того же EXCEL-я. Одним словом всего что может работать по технологии COM/DCOM.

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

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

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

Не к теме.
Хаба хаба AlexCzech-му.
Недавно в какойто статейке вычитал, что мир движется уже к пятизвенной архитектуре. Так что есть еще куда стремиться .

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

Добрый день.

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

Компания живет и развивается. Если бы было все так плохо она давно бы уже развалилась. Мастер весны 2004 года и Мастер лета 2005 это на мой взгляд две разные компании.

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

to Компостеров.
У Вас работали разработчики бизнес приложений. Как работает система внутри они и не обязаны были знать совсем, их задача автоматизация бизнес процессов. А возможно просто не хотели вдаваться в подробности. Если Вам действительно интересна внутрееняя архитектура и функциональность, то Вам необходимо спрашивать об этом у системных программистов.
Основная работа ведется с объектами н.р. "Договор" "Договро страхования" "Объект страхования" "Риск" и т.д. с их атрибутами и методами. Методы объектов можно вызывать на стороне клиента или на стороне сервера. К атрибутам и методам объекта можно обращаться через точку например "Договор.Договор Страхования.Собственный Договор Страхования.Номер Договора" и совсем не важно как все это дело лежит в базе данных и в каких таблицах. Разработчик системы оперирует теми же терминами что и пользователь.