|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
Уважаемые форумчане. Прошу опытных специалистов и особенно 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.создать дружественную конкуренцию команд разработчиков. Для этого взять нового гуру выбранной платформы. Но использовать аутсорс (для уменьшения стоимости владения), с которого бы он "не слезал". Для начала взять один участок, попробовать его подключить новой надстройкой к хранилищу. посмотреть сроки и как люди будут работать. Таким образом начнет постепенно вызревать новое стандартизованное представление данных и понимание бизнес- процессов. Иначе придется "лепить" ИС в старом ключе. Жизнеспособен ли подход? Если да, то какую посоветуете платформу? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 15:40 |
|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
в свое время (2008 год) писался диплом в MBA . Это компиляция. Тоже у предприятия были подобные вопросы ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 17:34 |
|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
iscrafm, Accces + MS SQL считаете бредовым подходом для макетирования и работы на первых порах или нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 17:54 |
|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
serg0265iscrafm, Accces + MS SQL считаете бредовым подходом для макетирования и работы на первых порах или нет? не считаю. Достаточно хорошая, имхо, связка для макетирования. Если есть время и ресурсы для макетирования, то почему-бы и нет. Вполне. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 18:08 |
|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
serg0265iscrafm, Accces + MS SQL считаете бредовым подходом для макетирования и работы на первых порах или нет?Только макет пойдёт в продакшен :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 18:22 |
|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
iscrafm, По скорости построения кто выигрывает: Access(Если конечно оказывается, что функционал может быть реализован) или .Net ? Думаю Access+SQL. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 18:24 |
|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
alexeyvg, вполне работоспособные приложения могут получаться. Проверено. Если конечно с "прямыми" руками подходить. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 18:26 |
|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
serg0265alexeyvg, вполне работоспособные приложения могут получаться. Проверено. Если конечно с "прямыми" руками подходить.Да я не против аксеса, нормальная платформа для клиента... ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 18:32 |
|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
Сталкиваюсь часто, что срабатывает стереотип недооценки Access. Как правило тех кто его плохо знает. Что за iscra? Рекомендуете продукт? Странно, что мало внедрений, если он такой интересный... ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 18:38 |
|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
serg0265iscrafm, По скорости построения кто выигрывает: Access(Если конечно оказывается, что функционал может быть реализован) или .Net ? Думаю Access+SQL. из этих связок не пользуюсь ничем. Но, в свое время тестировали, конечно access ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 18:41 |
|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
Access непригоден для коллективной разработки (проект не положить в source control), не поддерживает ООП, ужасно неудобный и неэргономичный UI в том что касается средств разработки (причём в 2007 стал ещё хуже). ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 22:55 |
|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
Kyubeeне поддерживает ООПэто вообще на что-то влияет? Тем более в бизнес-приложениях, где кроме лишних телодвижений ничего не привносит ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 23:09 |
|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
serg0265, Критерии оптимальности в большей степени нереальны с самого начала. Ну неможет дешевое решение соответствовать остальному. Также нельзя внедрить "быстро" - уже столько палок сломали на этом что даже нет желания повторяться. Подход в корне неправильный. Начните с пустого листа и нарисуйте бизнес процессы и документооборот к ним. Потом долго и упорно курите бамбук пока не приведете к более-менее нормальному виду. Дальше берите какой-то нижний блок, составляйте ТЗ и находите исполнителя. Думаю к этому времени вы уже поймете какая должна быть БД и средства разработки. Можете пойти по пути готового решения. Но тогда придется использовать то что там реализовано. Т.е. отказаться от ваших "хотелок". ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 23:37 |
|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
Злой Бобрserg0265, Критерии оптимальности в большей степени нереальны с самого начала. Ну неможет дешевое решение соответствовать остальному. Также нельзя внедрить "быстро" - уже столько палок сломали на этом что даже нет желания повторяться. то, что вы сломали палки совершенно не означает что нельзя. Другие не ломали ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2012, 01:39 |
|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
iscrafmKyubeeне поддерживает ООПэто вообще на что-то влияет? Тем более в бизнес-приложениях, где кроме лишних телодвижений ничего не привносит В бизнес-приложениях часто приходится делать документы, представляющие собой вариации какого-то базового (добавлены несколько полей/подчинённых таблиц + вычисления). На языках без ООП, в зависимости от разработчика, получаются или тонны копипасты, или феерическое спагетти. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2012, 02:14 |
|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
Kyubeeiscrafmпропущено... это вообще на что-то влияет? Тем более в бизнес-приложениях, где кроме лишних телодвижений ничего не привносит В бизнес-приложениях часто приходится делать документы, представляющие собой вариации какого-то базового (добавлены несколько полей/подчинённых таблиц + вычисления). На языках без ООП, в зависимости от разработчика, получаются или тонны копипасты, или феерическое спагетти. да ты что Извини за сарказм, ну уж очень забавно ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2012, 02:15 |
|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
Kyubee, бизнес-приложения, в большей степени, живут на сервисных или функциональных рельсах. А на рельсах ООП они живут только в головах программеров, которые в них, к сожалению, ничего не смыслят ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2012, 02:17 |
|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
iscrafmKyubee, бизнес-приложения, в большей степени, живут на сервисных или функциональных рельсах. А на рельсах ООП они живут только в головах программеров, которые в них, к сожалению, ничего не смыслят +1 Захотелось чего-то большого и чистого. Помыл слона. Не то... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2012, 11:08 |
|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
KyubeeНа языках без ООП, в зависимости от разработчика, получаются или тонны копипасты, или феерическое спагетти.Фееричный пост. Никакому документу не нужен ООП. ООП реально нужен только для обработки фундаментальных понятий - список, карточное представление. Ну плюс какие-то мелочи. Подавляющее большинство систем понятия не имеют про ООП. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2012, 11:10 |
|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
>Подавляющее большинство систем понятия не имеют про ООП Лет 50 назад подавляющее большинство систем не знало про компьютеры (тоже были "реально" нужны только где-то неизвестно где). >ООП реально нужен только для обработки фундаментальных понятий - список, карточное представление. Ну плюс какие-то мелочи. ООП _вы лично понимаете как использовать только для_ обработки фундаментальных понятий - список, карточное представление. Некоторые продвинулись дальше. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2012, 15:34 |
|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
KyubeeНекоторые продвинулись дальше.Дальше, это куда ? :) Между документами не должно быть плотной иерархичекой связи. Потому что в случае изменения поведения базового документа изменится работа и всех потомков. Не факт что правильно. В процессе доработок постоянно переписывать навороченные классы большой вложенности... Это жесть. ООП ради ООП. Именно по этой причине ООП не прижилось в РСУБД. А СУБД - основа любой уч. системы. Вот только не надо тут про Каше, ОК ? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2012, 15:52 |
|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
Kyubee>Подавляющее большинство систем понятия не имеют про ООП Лет 50 назад подавляющее большинство систем не знало про компьютеры (тоже были "реально" нужны только где-то неизвестно где). >ООП реально нужен только для обработки фундаментальных понятий - список, карточное представление. Ну плюс какие-то мелочи. ООП _вы лично понимаете как использовать только для_ обработки фундаментальных понятий - список, карточное представление. Некоторые продвинулись дальше. интересно кто и куда продвинулись? Или это просто так сказано? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2012, 16:08 |
|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
LSVВ процессе доработок постоянно переписывать навороченные классы большой вложенности... Это жесть. ООП ради ООП. я думаю коллега просто выдает желаемое за действительное. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2012, 16:09 |
|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
LSVМежду документами не должно быть плотной иерархичекой связи. Не делай плотную. Сделай для начала один уровень: "Документ" -> "Все документы (наследники) здесь на этом уровне". Ведь у тебя же не вся БД из документов состоит? А общие свойства и методы для всех документов всё-таки выделить можно. LSVПотому что в случае изменения поведения базового документа изменится работа и всех потомков. Не факт что правильно. Не факт что правильно так делать? Если ты знаешь об этой особенности при проектировании - значит всё зависит от тебя... :) Не факт что правильно будет работать после изменения? Это уже зависит от головы... Каждый сам выбирает между: 1) много думать - чуть-чуть поменять - много проверить 2) меньше думать - много-много поменять - много проверить И где-тут больше риска? LSVВ процессе доработок постоянно переписывать навороченные классы большой вложенности... Это жесть. ООП ради ООП. Не пиши навороченные классы большой сложности. VCL/.NET/J2EE посложнее будут. Живы. LSVИменно по этой причине ООП не прижилось в РСУБД. А СУБД - основа любой уч. системы. Смотря что подразумевать под этим. Cоздание ПервКлюча совпадающего с ВнешКлючом на таблицу-родителя (наследование) с CASCADE DELETE ("обрезанный" полиморфизм для DELETE) - очень удобной моделью оказалась в моей практике :). ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2012, 16:28 |
|
Стратегия перехода на цивилизованные рельсы.
|
|||
---|---|---|---|
#18+
Не делай плотную. Сделай для начала один уровень: "Документ" -> "Все документы (наследники) здесь на этом уровне". Ведь у тебя же не вся БД из документов состоит? А общие свойства и методы для всех документов всё-таки выделить можно. И зачем тогда этот один уровень ? В чем тогда преимущество ООП ? Общие свойства ? Хе-Хе... Например у нас есть не только документы, а псевдодокументы. В системе они видны как отдельный тип, но на самом деле это примерно как дополнительная спецификация для одного из обычных д-тов. Или вообще без нее. У каждого из этих псевдо- может быть особое поведение. Причем заранее (при создании движка системы) нельзя предсказать, что со временем появится именно такой документ. ООП для документов практически не создает особых удобств, т.е. без ООП можно обойтись. А вот сложность ООП может быть весьма высокой и размазанной по куче модулей (как в VCL). Ну толку, что примерно так сделано в Акзапте ? Выходит афигенная сложность, как правило немногим посильная. Выигрыш то в чем ? В скорости и стоимости разработки ? БУГАГА. Там она черепашья и по цене золота. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2012, 18:03 |
|
|
start [/forum/topic.php?fid=33&fpage=22&tid=1547909]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
27ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 129ms |
0 / 0 |