Абсолютно согласен - всякую "малую механизацию" c помощью Accessa, Excel-a и какой-то матери можно и нужно делать внутри.
Но когда речь идет именно о более или менее амбициозной РАЗРАБОТКЕ, полностью занимающей ресурсы одного или нескольких программистов на срок неделя и более, и ставящей задачу не "затыкания дыр", а выдачи на гора какой-то СИСТЕМЫ, тут все мои аргументы вступают в силу.
А проблем взаимодействия с поставщиками - как правило, всегда выше крыши, и ничего нового тут нет. Но поверьте, если бы вы писали эту программу самостоятельно, проблем для фирмы было бы гораздо больше :)
Из ответа сотруднику, который отослал меня на эту статью. Внимательно почитал «почиталку»... Я бы согласился с автором (впрочем во многом согласен и более того считаю, что основные программные продукты – финансового и складского учета должны быть именно «фирменными» [здесь и поддержка изменений в законодательстве и отчетности и важные прочие мелочи], однако когда необходимо быстро и оперативно решить какие-то локальные задачи (или задачи не требующие строгой финансовой отчетности), то думаю нужно использовать свои умственные резервы. Например: Программ...>>>>
По состоянию на момент написания статьи Access-97 так и делал - проверено руками. Если сейчас он поступает как-то по другому - это интересно. Описали бы, как именно.
А поповоду умности - вас никогда не доставал "ненавязчивый сервис" WinWord-a, который считает, что он меня лучше знает. что я имею в виду? Время от времени он начинает вытоварять с правописанием или с таблицами что-то такое, что непонятно, как это вообще прекратить.
Это как моя собака, Которая Знает Дорогу, и в результате частенько пытается бежать не туда, куда мы с ней идем, и ее приходится все время одергивать :)>>>>
я понимаю, что статья давняя... мне ее переслал сисадмин
это из статьи...
"Еще веселее с Access-ом. Он, как все мелкомягкие продукты, считает себя самым умным, и разрешает редактировать результат запроса без ограничений! Правда, что он при этом делает... Например, в приведенном выше примере он без малейших сомнений и колебаний изменит название товара в таблице товаров. Если добавить запись, и ошибиться в названии фирмы на один символ, он также уверенно добавит запись в таблицу фирм. Как он правильно разбирается, что нужно удалять в этом случае, для меня загадка..."
полная чушь.. не знаю как этот чел знает знает Delphi и все остальное, но Access он не знает вообще :-))))))
и по фразе "Он, как все мелкомягкие продукты, считает себя самым умным" сразу понятно кто пишет:-)))
Фантастическая статья - впечатление такое как-будто читаешь свои тайные мысли... Хотелось бы спросить у автора: не известны ли ему российские производители КИС с похожими приёмами работы и анализа. Поясню - 3 года плотно занимаюсь внедрением КИС одного российского производителя, так сказать "снизу" т.е. в должн. программист одной крупной металлургической компании. Бюджет внедрения более млн.$, может уже более двух... результата ноль! Руководство развращено взятками, даже младшим руководителям предлагают отступные за подписание актов приёма в эксплуатацию. От знакомых, внедряющих ИС других производителей как со стороны заказчика так и исполнителя, знаю что подобные ситуации обычны, с той лишь только разницей что приемлемым результатом считается отличный от нулевого. Кто-нибудь работает нормально! после прочтения вашей статьи возникла надежда - что есть нормальные разработчики, может вы назовёте их.>>>>
Много ... ... много умных и правильных слов ... но
Кем пишутся те большие проекты? Случайно не марсианами? ... На удивление нет ... А подозреваю я пишутся они теми самыми "как правило бывшими сотрудниками" ... которые не нашли себе применения на родном предприятии ... и по этому теперь продают свое "самовыражение" ...
Насчет грамотности специалистов. На мой взгляд автор очень пренебрежительно отзывается в первую очередь в свой собственный адрес. Что начинает делать предприятие купив систему? Ответ очевиден: переписывать, переделывать, донастраивать и т.д. П...>>>>
Я что-то пропустил? :-) Единое информационное пространство это что? Если это возможность свободно обмениваться информацией, то никакая комплексная АС для этого не нужна, мы вот с Вами свободно обмениваемся репликами без всякой комплексной системы. Если же единое информационное пространство это один большой мэйнфрейм на всю компанию, то извините, это уже не корпорация получается, а музей вычислительной техники.
Впрочем, интегроровать друг с другом системы, которые задумывались как комплексные, действительно сложно. И проблема, imho, здесь не в количестве систем а в архитектуре.>>>>
IMHO островная автоматизация плоха не тем, что не все операции автоматизируются, а тем, что не создается единого информационного пространства.
Корпоративная информация рассредотачивается по разным подсистемам, увязать которые для получения целостной картины зачастую оказывается сложнее и дороже, чем написать "с нуля" комплексную систему.
Хотя, надо сказать, "монстры" типа R3 давно вызывают у меня сильные сомнения - я практически не знаю успешных примеров внедрения (говорят, есть одно образцово-показательное в БелгородЭнерго, но оно чуть ли не единственное).
И в случае R3 вы похоже, правы с финансово-каптиализационными аспектами - рапорт о внедрении R3 (и даже о начале такового) увеличивал каптиализацию компании - акционеры обычно считают, что "совершенствование системы корпоративного управления" - правильная трата средств (по крайней мере, до недавнего времени так было). Так что в значительном числе случае попытки внедрения R3 - это дань моде.
А пассаж насчет серьезных менеджеров я не понял...>>>>
И все же давайте еще раз все по порядку: Чем плоха «островковая» она же «лоскутная» автоматизация? Года с 1995 в народное сознание активное внедряется идея «универсального клиента» (правда Sun говорил что универсальный клиент это VMJ, Microsoft что Wintel с офисом, Netscape что-то про навигатор с javascript. но это не суть важно.). От множества серверов в этом случае не уйдешь, но TCO за счет поддержки клиента не увеличит. Кроме того, если вспомнить пассаж Радучела о том что «межоперабельность(т.е. способность интегрироваться с другими системами) ...>>>>
Собственно, материалы этого топика уже почти образовали то самое эссе (Купить или не купить, или почему приходится разрабатывать собственное ПО), которое я анонсировал, но в течение 8 лет так и не собрался написать...>>>>
Хм... Зашел на этот сайт случайно, по ссылке на Тимура Шаова, а тут такой интересный топик :o). Впрочем, насчет авторской песни тоже чего-нибудь сочиню, но сначала про работу. Сразу подчеркну, что тупая статистика личных наблюдений дает подавляющее превосходство "своих сил", ну хоть ты убейся. И эту линию сейчас буду гнуть долго и нудно. Я хорошо помню, как внедрялось годами (!) изделие крупного солидного ПКБ на металлургическом предприятии в 80-х годах, и каков оказался его жизненный цикл. Как внедрялась западная банковская система в крупном региональном банке, и с каким треском это...>>>>
Всю жизнь я был противником собственной разработки. Может быть по причине продолжительной работы в Инкомбанке с собственной АБС, может быть же в силу каких-то других причин. Однако, опыт последних двух лет мешает оставаться мне столь категоричным, потому как: - Вопрос писать или не писать состоит из двух вопросов: купить готовое или разработать заново и разработать своими силами либо привлечь аутсорсера. Соответственно «писать или не писать» перестает быть дилеммой. - 21 век на дворе, однако. Гордость «покупателя» в глобальной экономике не позволяет действовать в парадигме «не считайте себя умнее других, пользуйте SAP/R3». Что делать с теми же конкурентными преимуществами любимой фирмы, состоящими, например, в том, что отдел из трех-пяти человек поддерживает продажи на сотни MUSD в год, с присущим только нашим сотрудниками users experience и т.п. Коробочные решения, как известно, запросто убивают ключевые компетенции. - Нельзя игнорировать «новые» идеи вроде XP. Вряд ли поставщики коробок могут ответить что-либо вразумительное Кенту Беку, который говорит о том, что стоимость внесения изменений вовсе не обязана расти во времени по экспоненте.
Согласен, что самовыражение программистов за счет компании – явление отвратительное. Однако, ответ на вопрос «писать или не писать» вряд ли может быть столь категоричным.>>>>
Вопрос в степени интеллектуальности терминала и характере трафика. Такими тупыми, как символьные терминалы, они уже не будут, а все, что поумнее - уже можно считать клиентом.
Браузер, например - клиент или терминал? А если с JS? А если с Java или .NET? И т.д.
Все равно остается вопрос распределения полномочий и организации работы множества медленных пользователей с быстрыми компьютерами.>>>>
Есть еще одна популярная методология постороения СУБД - UML ориентированные.
Например geodatabase ArcInfo - человек строит UML-диаграммы - набор обьектов с аттрибутами - и затем программа хранит структуру и бизнес-логику в обычной реляционной базе .>>>>
В этом месте можно было бы, выражаясь специфически, обоюдно "зафиксировать прибыль", но позволю себе заметить следующее. Ни одна современная система автоматизации (любая) принципиально не может быть доделана (как принципиально не может быть доведена до совершенства любая человеческая деятельность), о чем, кстати, и сам уважаемый автор пишет в "Автоматизации хаоса" (помните: "разумная организация данных стимулирует возникновение разумных способов работы с ними, и позволяет осуществлять некий ''ползучий'' реинжениринг бизнес-процессов, когда старые процессы отмирают за их очевидной абсурдностью, а новые возникают как бы сами собой...)". Никто никогда еще не сделал ни одного продукта (за исключением вырожденного случая, когда продукт не предназначен для какого-либо полезного использования), в котором не было бы недоделок к моменту завершения любого этапа разработки. Поэтому модифицируемость при приемлемых затратах всегда ключ к успеху любой технологии информатизации. Остальное - предмет дискуссий для гуру.>>>>
1. Да, конечно, в этом нет ничего нового. И я не претендую на "открытие америк". Все разумные разработчики всегда это подуспудно чувствовали.
Но увы, внятных формулировок этих принципов на русском языке мне встречать не приходилось.
И одно дело подспудно чувствовать, совсем другое - иметь изложенную методологию, пригодную к использованию - не все такие грамотные, как коллега Голованов. И о том, что эти тексты востребованы, свидетельствует обширная почта от весьма профессиональных людей.
2. Наши оффшорники пока занимаются в основном освоением средств спецификаци...>>>>
Любопытно. Высказывание коллеги Кузнецова конкретизирует неясный протест, растущий в подсознании по мере чтения статьи. Это протест теперь можно выразить в двух тезисах.
1. В автоматизации "от данных" нет ничего нового. В действительности с начала 90-х периодически появляются техологии разработки, так или иначе отталкивающиеся от модели данных (DataRun etc), да известная в народе "парочка" ERWin/BPWin может быть сколько-нибудь продуктивно использована, если разработчик придерживается цикла "определение требований - создание модели данных - создание приложений по...>>>>
1. При создании ББ никаких наработок не использовалось. Все писалось с нуля. Активная фаза разработки составили 3 месяца до ввода системы в эксплуатацию практически в полном объеме (1996 год). С тех пор она потихоньку дорабатывалось, и зимой 1998г. была переписана под Interbase.
2. Человеческие ресурсы были я (где-то на половину своего рабочего времени) и Миша Потемкин (на начальной фазе разработки - первые два месяца) и впоследствии при переносе на Interbase (еще два месяца).
3. Готовые системы, сколько нибудь пригодные к использованию, появились на рынке в начале 1998 года, и все они были существенно слабее, чем ББ к тому времени.
4. Да, хотелось бы некий CASE, оперирующий понятиями, описанными в той самой статье, по поводу которой мы общаемся, который строил бы сразу и структуры БД, и формы с набором стандартных возможностей аля ББ, допускающие кастомизацию.>>>>
Спасибо за ответ. Еще несколько замечаний по отдельным пунктам. 2. Я не знаю, использовались ли при создании ББ какие-то уже имеющиеся наработки (скорее всего да), но то, что у него находится внутри явно не представляет собой быстрое решение в ограниченное время, достаточно много всего "заточенного". А кто являлся ресурсами (человеческими) я примерно представляю - достаточно могучие люди (по-моему весь Либертариум и др.) 3. Я достаточно осведомлен о попытках альтернативных разработок и покупок готовых систем. Тут дело скорее всего в отсутствии нормального IT-manager-a. 1998 год и "объединение", конечно, сыграли свою роль. Дело не в уникальности и неповторимости ББ. 4. Что есть еще более высокоуровневый инструментарий? Некое CASE-средство, которое "выше" используемого Delphi?>>>>
1. Конечно же, ББ - не промышленный продукт, и никогда не претендовал на это... Это система, которая делалась в конкретной ситуации для покрытия конкретных потребностей.
2. Утверждается, что только использование описанной методологии позволило ЗА ТО ВРЕМЯ, КОТОРОЕ БЫЛО, И С ТЕМИ РЕСУРСАМИ создать систему, реально помогающую организации в работе.
3. Учитывая, что, как вы написали, предметная область быстро меняется, скорее всено, никакая другая методология успеха не принесла бы вообще. По крайней мере, попытка альтернативной разработки, начатой в Ринаке, и продолжающейся в Никойле по сей день, на которую потрачено существенно больше (на порядок) денег, пока не сошлась.
4. Отмеченные недостатки (несопровождаемость, трудоемкость добавления новых таблиц и др.) обусловлены как раз отсуствием высокоуровневого инструментария, на которое я сетую.
Но отнюдь не использованной моделью - если бы перед вами была бы гора плохо связанных АРМов, ситуация с сопровождаемостью была бы еще хуже.
5. "Интерфейсу" видать, не хватает свежего контента, и они попросили разрешения на публикацию моих измышлений. Я, естественно, не отказал.>>>>
Я занимался сопровождением и развитием этой системы с зимы 1998 по осень 1999 года (тогда мы с вами несколько раз и встречались). Не скрою "движок" ББ меня порой восхищал, но одно сильное чувство тогда и сейчас портило все - эта система была и думаю, остается, если еще работает, в большой степени несопровождаемой и нерасширяемой, что все-таки имеет первостепенное значением при эксплуатации системы в такой большой компании. Да, я через несколько месяцев начал добавлять новые функции и исправлять ошибки, но трудозатраты были не адекватны. А ведь данная предметная область очень быстро (не в глобальных, конечно, понятиях), но развивается. Мыслей было много, но это не промышленный продукт. Что, например, стоило добавление какого-то справочника... Был сделан продукт, позволяющий достаточно удобно, но с известными ограничениями, работать с несколькими распухшими плоскими таблицами, гоняя при этом по сети огромные блоки данных. А причина написания данного замечания – я сегодня обнаружил ссылку на эту статью в рассылке interface.ru. Казалось, что одной публикации (по-моему 2 года назад в Компьютерре) было достаточно для изложения столь прогрессивных мыслей.>>>>