Уважаемые форумчане.
Прошу опытных специалистов и особенно IT-руководителей поделиться опытом не революционного, а эволюционного развития автоматизации в организации с филиальной структурой. Сам имею опыт автоматизации подобных структур "с нуля". Но посчитал полезным обменяться профессиональным мнением, подискутировать и прийти к самому оптимальному решению. Стратегия может быть ориентирована либо на своих разработчиков, либо на аутсорс, либо на гибридную модель.
Критерии оптимальности по приоритету : 1. наименьшая стоимость владения решением. 2. быстрота модификаций 3. высокая скорость внедрения 4. несильная зависимость от одного сотрудника.
Исходная информация . 1.Есть много отделов со своими "лоскутами" данных: Access, FoxPro, Excel, дремучие Unix БД и т.д. и т.п. Итого около 20 всевозможных "хранилищ". 2.Еще есть самый большой кусок данных - система (назовем АС) на основе БД MS SQL. Написана на .Net. Ей удалось охватить максимальное количество данных и процессов в компании, около половины. Делалась система 2 года. 3.Бухгалтерию начали внедрять на 1С платформе. Почти настроен обмен проводками 1С с АС. 4. Блок расчетов на Юниксе. 5. Бизнес-процессы (БП) сильно условны, запутаны и несогласованны. 5. Куча филиалов, которых тоже надо охватывать автоматизацией. 6. есть сторонние потребители информации, значит решение д.б. вэб-ориентированным. Вот такой зоопарк!
Что сейчас категорически не устраивает : 0. АС не построена по трехуровневой модели проектирования. Поэтому недостаток гибкости и прозрачности у системы в целом. 1.Не такая быстрая разработка как хотелось бы 2.зависимость от одного разработчика 3.имеющиеся интерфейс и идеология плохо ориентированы по ролям заказчика (всех нагнули к одному интерфейсу). 4.медленное воплощение изменений 5.непрозрачность и плохое описание (постороннему невозможно быстро "въехать") 6. База "пухнет" быстрыми темпами (полгода - 100Гб, почему - не понятно). ПО не предусматривает масштабирования всех уровней. Скоро некуда ставить оперативку будет. Что тогда? 7.оставшиеся сотрудники категорически отказываются работать с интерфейсом АС, к которому их подталкивают и который им неудобен.
Посыл избежать революции - полной смены команды разработчиков, стройки на чистом месте, мучения измученного автоматизацией персонала по десятому разу т.д. Плавное перерастание системы в продукт, не зависящий от конкретных людей. Повернуть приложение "лицом" к нуждам заказчика. Не "нагибать" его и не приводить "к общему знаменателю". Уточнять и быстро корректировать приложение в процессе понимания процессов и уточнения ТЗ.
Решение 1."неохваченные" области автоматизации с помощью другой платформы быстрой разработки и модификации (типа 1С УПП, SharePoint, ASP.Net или что еще посоветуете). Это будет новая "надстройка". Главное чтобы разработка приложения шла не от кода, а от цели (как это в FoxPro, Access). Нужен бизнес-конструктор 2. Основа старая - уже накопленные данные в общем хранилище БД на SQL. 3.Использовать технологию системной шины данных для обмена между всеми "лоскутами". 4.создать дружественную конкуренцию команд разработчиков. Для этого взять нового гуру выбранной платформы. Но использовать аутсорс (для уменьшения стоимости владения), с которого бы он "не слезал".
Для начала взять один участок, попробовать его подключить новой надстройкой к хранилищу. посмотреть сроки и как люди будут работать. Таким образом начнет постепенно вызревать новое стандартизованное представление данных и понимание бизнес- процессов. Иначе придется "лепить" ИС в старом ключе.
Жизнеспособен ли подход? Если да, то какую посоветуете платформу?

iscrafm, Accces + MS SQL считаете бредовым подходом для макетирования и работы на первых порах или нет?

iscrafm, По скорости построения кто выигрывает: Access(Если конечно оказывается, что функционал может быть реализован) или .Net ? Думаю Access+SQL.

alexeyvg, вполне работоспособные приложения могут получаться. Проверено. Если конечно с "прямыми" руками подходить.

Сталкиваюсь часто, что срабатывает стереотип недооценки Access. Как правило тех кто его плохо знает.

Что за iscra? Рекомендуете продукт? Странно, что мало внедрений, если он такой интересный...

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

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

Kyubee, "Access непригоден для коллективной разработки (проект не положить в source control), не поддерживает ООП, ужасно неудобный и неэргономичный UI в том что касается средств разработки (причём в 2007 стал ещё хуже)."

Разве? А инструменты перекомпиляции Access в VB? Как нет ООП? Можно использовать любые объекты подключаемых билиотек и создавать свои. UI на мой взгляд удобный и лаконичный по сравнению с другими.

Злой Бобрserg0265,

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

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