09.11.2002 14:56 Максим Смирнов Замечание по теме: ПИСАТЬ ИЛЬ НЕ ПИСАТЬ или почему не стоит разрабатывать собственное программное обеспечене

Всю жизнь я был противником собственной разработки. Может быть по причине продолжительной работы в Инкомбанке с собственной АБС, может быть же в силу каких-то других причин. Однако, опыт последних двух лет мешает оставаться мне столь категоричным, потому как:
- Вопрос писать или не писать состоит из двух вопросов: купить готовое или разработать заново и разработать своими силами либо привлечь аутсорсера. Соответственно «писать или не писать» перестает быть дилеммой.
- 21 век на дворе, однако. Гордость «покупателя» в глобальной экономике не позволяет действовать в парадигме «не считайте себя умнее других, пользуйте SAP/R3». Что делать с теми же конкурентными преимуществами любимой фирмы, состоящими, например, в том, что отдел из трех-пяти человек поддерживает продажи на сотни MUSD в год, с присущим только нашим сотрудниками users experience и т.п. Коробочные решения, как известно, запросто убивают ключевые компетенции.
- Нельзя игнорировать «новые» идеи вроде XP. Вряд ли поставщики коробок могут ответить что-либо вразумительное Кенту Беку, который говорит о том, что стоимость внесения изменений вовсе не обязана расти во времени по экспоненте.

Согласен, что самовыражение программистов за счет компании – явление отвратительное. Однако, ответ на вопрос «писать или не писать» вряд ли может быть столь категоричным.>> >>

Тема: ПИСАТЬ ИЛЬ НЕ ПИСАТЬ или почему не стоит разрабатывать собственное программное обеспечене

Автор: Автор: Прядкин Вячеслав Георгиевич  

Дата: 10.11.2002 11:08

Хм... Зашел на этот сайт случайно, по ссылке на Тимура Шаова, а тут такой интересный топик :o). Впрочем, насчет авторской песни тоже чего-нибудь сочиню, но сначала про работу. Сразу подчеркну, что тупая статистика личных наблюдений дает подавляющее превосходство "своих сил", ну хоть ты убейся. И эту линию сейчас буду гнуть долго и нудно. Я хорошо помню, как внедрялось годами (!) изделие крупного солидного ПКБ на металлургическом предприятии в 80-х годах, и каков оказался его жизненный цикл. Как внедрялась западная банковская система в крупном региональном банке, и с каким треском этот проект провалился. И как вылетел с работы хороший человек, чьей виной было то, что его банк имел покупную банковскую систему солидного российского производителя, которая не успела вовремя среагировать на внедрение 20-значного плана счетов. Да, у солидных продуктов есть очень сильная наукоемкая платформа, они сделаны толково, имеют цельную идеологию и хорошо структурированы и т.п. Но...
- "Покажите мне две одинаковые счет-фактуры, выписанные разными предприятиями одной и той же отрасли" (с) некий_старый_руководитель.
- Возьмите крупное российское предприятие. И попытайтесь вникнуть во все внутренние нюансы его документооборота, организационной структуры и не совсем очевидных извне внутриполитических дележей и дрязг. А теперь давайте затеемся внедрять умную чужую разработку. К примеру, R3. Что вылезет тут же ? Что в связи с законом о невозможности автоматизировать беспорядок данная система первым делом потребует изменения самой структуры управления, т.е. перераспределения ролей, к примеру, в заводоуправлении. Ну-ну. Чтобы такое протолкнуть, начальник местного АСУ должен обладать недюжинными полномочиями, которых у него, как правило, нет. Или этого должно сильно хотеть первое лицо, принимающее решения, при этом быть компетентным. Это, видимо, бывает. Но редко.
- Цена. Обычно исчисляется цифрами, грозящими для предприятия необратимыми последствиями в случае провала проекта. Ну или, как минимум, для лиц, принимавших решение о покупке.
- Гибкость. Очень важный критерий в российских условиях. Реагировать на изменения в налоговом, к примеру, законодательстве надо "вчера". Если между возниконовением срочной нужды и реакцией на нее проходит неделя-другая вместо дня-двух, начинаются серьезные неприятности.
- Стронний разработчик может обанкротиться, прекратить поддержку своего софта или выкинуть еще какую-нибудь пакость. Чтобы обезопаситься, сопровождающие продукт местные программисты должны иметь полный контроль над потрохами системы. Тоже сильно не очевидно.
- Ну и так далее и тому подобное.
Т.е. минусов не просто много, их критически много. В том числе применительно не только к бардачной промышленности, но и столь формализованной и вроде как организационно причесанной банковской сфере, на которую ссылается автор топика. Да, у каждого банка есть строго расписанный общероссийский план счетов, стандартные платежные документы и прочее "ядро". Услуги, подлежащие автоматизации, тоже вроде как у всех одни и те же. Вроде бы. Дебет-кредит, сальдо-бульдо, картотека один-два-три, вклады населения, кредиты и все такое. Если только банк мелкий и ни на что не претендующий. Но как только он затеивается создавать собственный расчетный центр, пытается озадачивать конкурентов чем-то свежим типа продавать ценные монеты или выходить на рынок ценных бумаг в качестве не посто купи-продай, но и предоставляя клиентам доступ к торгам on-line через свою спутниковую тарелку, да еще имеет развитую сеть филиалов и хочет иметь некий внутренний закрытый трафик документов, объем срочно требуемого софта покрывает "ядро" как бык овцу, причем идет под грифом строгой коммерческой тайны. И возникает идея, что иметь в базе данных собствнную схему того самого дебет-кредит - это не такой уж и big deal, и заключительные обороты в конце года - хоть и геморрой, но тоже можно описать своими силами. И централизованную бухгалтерию вместе с малоценкой и основными фондами вполне способен потащить один программист, вооружившись Oracle Forms. Причем все будет не на коленке склепано, а иметь очень наукообразный вид, и спросить будет с кого. Чтобы окончательно закруглиться с российскими реалиями, вернемся к промышленности, к тому самому заводу. 89 год. Министерство черной металлургии покупает чертову тучу западной супер-пупер техники плюс Unix/Oracle и сетевые кабели, и устраивает проект века "своими силами". Этот завод берется автоматизировать ввод заказов, этот берет на себя расценку, этот - оперативное планирование, через год встречаемся и продаем все это друг другу по сходной цене. Результат был не просто положительным. Он был ошеломляющим. В течение года на всех предприятиях были внедрены все системы верхнего уровня, еще через год был покрыт уровень цехового управления, после чего, ессно, каждый пошел своим путем, что-то подстроил под себя, что-то выкинул за ненадобностью или переписал заново, но в короткий срок была построена целая инфраструктура. Что самое забавное, не было каких-то особых проблем с внедрением, потому как вживлялось итерационно и с учетом местных условий, подстраиваясь на ходу. Сейчас там внедряют R3. Процесс идет уже несколько лет, потрачены колоссальные деньги, результат близок к нулю.

Значит ли это, что собственная разработка с моей кочки зрения - панацея ? Конечно, нет. Зачастую это "островковая автоматизация", слабый уровень взаимодействия проектов и копание под себя. Но эти проблемы легко решаются организационно и финансово, не так уж много для этого нужно.

14.11.2002 22:00 Andrey Akopyantc Замечание по теме: ПИСАТЬ ИЛЬ НЕ ПИСАТЬ или почему не стоит разрабатывать собственное программное обеспечене

По поводу единого информационного пространства см. например
http://akop.ru/personal/1234>> >>

14.11.2002 21:02 Максим Смирнов Замечание по теме: ПИСАТЬ ИЛЬ НЕ ПИСАТЬ или почему не стоит разрабатывать собственное программное обеспечене

Я что-то пропустил? :-)
Единое информационное пространство это что?
Если это возможность свободно обмениваться информацией, то никакая комплексная АС для этого не нужна, мы вот с Вами свободно обмениваемся репликами без всякой комплексной системы. Если же единое информационное пространство это один большой мэйнфрейм на всю компанию, то извините, это уже не корпорация получается, а музей вычислительной техники.

Впрочем, интегроровать друг с другом системы, которые задумывались как комплексные, действительно сложно. И проблема, imho, здесь не в количестве систем а в архитектуре.>> >>

14.11.2002 11:08 Andrey Akopyantc Замечание по теме: ПИСАТЬ ИЛЬ НЕ ПИСАТЬ или почему не стоит разрабатывать собственное программное обеспечене

IMHO островная автоматизация плоха не тем, что не все операции автоматизируются, а тем, что не создается единого информационного пространства.

Корпоративная информация рассредотачивается по разным подсистемам, увязать которые для получения целостной картины зачастую оказывается сложнее и дороже, чем написать "с нуля" комплексную систему.

Хотя, надо сказать, "монстры" типа R3 давно вызывают у меня сильные сомнения - я практически не знаю успешных примеров внедрения (говорят, есть одно образцово-показательное в БелгородЭнерго, но оно чуть ли не единственное).

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

А пассаж насчет серьезных менеджеров я не понял...>> >>

14.11.2002 00:19 Максим Смирнов Замечание по теме: ПИСАТЬ ИЛЬ НЕ ПИСАТЬ или почему не стоит разрабатывать собственное программное обеспечене

И все же давайте еще раз все по порядку:
Чем плоха «островковая» она же «лоскутная» автоматизация? Года с 1995 в народное сознание активное внедряется идея «универсального клиента» (правда Sun говорил что универсальный клиент это VMJ, Microsoft что Wintel с офисом, Netscape что-то про навигатор с javascript. но это не суть важно.). От множества серверов в этом случае не уйдешь, но TCO за счет поддержки клиента не увеличит. Кроме того, если вспомнить пассаж Радучела о том что «межоперабельность(т.е. способность интегрироваться с другими системами) ...>> >>

10.11.2002 21:57 Andrey Akopyantc Замечание по теме: ПИСАТЬ ИЛЬ НЕ ПИСАТЬ или почему не стоит разрабатывать собственное программное обеспечене

Учитывая, что гонорару там будет примерно на бутылку коньяка - ноу проблем!>> >>

10.11.2002 21:11 Прядкин Вячеслав Георгиевич Замечание по теме: ПИСАТЬ ИЛЬ НЕ ПИСАТЬ или почему не стоит разрабатывать собственное программное обеспечене

Гонорар - на троих ! :o)>> >>

10.11.2002 19:33 Andrey Akopyantc Замечание по теме: ПИСАТЬ ИЛЬ НЕ ПИСАТЬ или почему не стоит разрабатывать собственное программное обеспечене

Собственно, материалы этого топика уже почти образовали то самое эссе (Купить или не купить, или почему приходится разрабатывать собственное ПО), которое я анонсировал, но в течение 8 лет так и не собрался написать...>> >>