>> если уж строить свою собственную «систему планирования», то на основе инструментария, предлагаемого выбранной «системой учета», Вы согласны?
Отчасти. Если мы говорим лишь об штучной инсталляции такой «учетной системы», то вполне закономерно нагрузить ее и кастомным функционалом «планирования». Однако если мы желаем иметь ее множество инсталляций, например в каждом магазине, кои у нас исчисляются десятками, быть может сотнями, то расстановка кастомизированных версий коробочного изделия по существенно увеличивает количество рисков поддержки и обновления такого продукта.
Что касается рисков размазывания функций планирования по бизнес-подразделениям, не моих компетенций дело, но с моей точки зрения это тоже весьма весьма и рискованно.
Если смотреть с этой точки зрения, мне кажется абстрагирование бэк-офиса от фронт-офиса, не такая уж и плохая идея.
>> Если компания нанимает хотя бы 3-4 профессионалов
Я так полагаю, Вы сейчас говорите о случае, когда компания заведомо не имеет в своем штате сильной команды бизнес-технологов и аналитиков. Тогда да, привлечение внешнего ресурса — единственный выход. Но мне кажется естественным, если компания пожелает оставить знание об особенностях протекании своих бизнес-процессов на своей стороне. В этом случае даже привлечение внешнего ресурса не избавляет компанию от необходимости нанимать этих 3-4 профессионалов для аккумулирования опыта. В противном же случае, компания обречена на заключение долгосрочных отношений с подрядчиком, что полностью нивелирует весь профит от «эпизодичности» в потребности такого рода отношений.
>>Короче, я остаюсь при своем мнении, извините.
Я не имею целью Вас переубедить — ни в коем случае. Мне просто интересны Ваши тезисы. Они дополняют сложившуюся у меня картину бытия, побуждают меня к размышлениям.
dzhe, я внимательнейшим образом обдумал множество озвученных Вами тезисов (хоть и не могу похвастать, что обдумал их все), и даже несколько затрудняюсь определиться в ответ на какой из Ваших постов выложить результат этих мыслей, потому выбрал первый попавшийся.
Мне кажется следует разделить понятия «учетная система» и «система планирования ресурсов». Учетная система просто регестрирует бизнесс-факты, система планирования принимает бизнес-значимые решения на основе этих данных.
Разработка собственной учетной системы действительно может занять огромное количество человеко-лет. Всяческие справочники, реестры, регистры, работа с кассовым оборудованием, сканерами и пр. пр. В индустрии действительно присутствует множество готовых решений, в том числе и коробочных. Использовать внешний ресурс для внедрения подобных систем, интеграции, обучения персонала — очевидное и верное решение, это действительно обойдется многократ дешевле нежели реализация собственными силами.
Однако система планирования — совсем другой разговор. Здесь нет устоявшийся практик, каждый бизнес владеет собственным ноу-хау, который позволяет ему быть более или же менее успешным. Это знание аккумулируется в подразделениями бизнес технологий, постоянно оттачиваетя, уточняется и исправляется бизнес аналитиками. Отдавать эти подразделения на аутсорс — очень большой риск потерять весь бизнес. Реализация же этих технологий, как правило не требует большого количества ресурса. Один — два толковых разработчика с лихвой покроют потребности каждого из контуров (финансового, товарного...) организации весьма внушительных размеров. Для реализации алгоритмов ассортиментного планирования, прогнозирования, расчета потребностей, выбора схемы снабжения, оптимального поставщика, формирования заказов, графика оплат, и пр. пр. не на столько уж и много кодинга требуется. Но эти алгоритмы постоянно уточняются, изменяются, исправляются на протяжении всего цикла жизни предприятия, и использование внешнего ресурса, здесь, оказывается не адекватно дорого. Как я уже говорил, аналитику и технологии во внешний ресурс — не отдашь, а удельная доля работ разработчиков в этих доработках не так уж и велика.
Рекусривные запросы — нативный способ обработки иерархических данных. Если я не ошибаюсь он даже стандартизирован SQL2003
Здесь же представлена свистелка, которая призвана облегчить построение материализованного пути — способа, придуманного чтобы как-то компенсировать недостаток средств работы с иерархическими данными в ранних версиях SQL. Мне кажется было бы разумно, если бы были представлены аргументы использования ее против использвания рекусривных запросов и была бы ограничена область применения предлагаемой методики.
Если вы приводите в пример кадровую политику именно этой организации, смею вас заверить, многие торговцы пончиками, производят куда более тщательный отбор нанимаемого персонала. А привлечение БиТ к проекту вовсе не уберегает заказчика от того, что на проект придет куча сброда, не прижившегося на другом проекте. И это при том, что БиТ, сам по себе, не так уж и плох, и даже хорош.
>> откуда-то вдруг в непрофильной компании появятся программисты, более квалифицированные, чем в компании, на этом самом софте специализирующейся?
Почему вдруг нет? Почему квалифицированные кадры должны сосредотачиваться именно в софтверных компаниях? Среди моего окружения я наблюдал достаточно случаев, когда устав от этих бесконечных внедрений, сегодня — здесь, завтра — там, есть проект — живешь, нет — лапу сосешь, но набрав при том себе внушительное резюме, внушительную коллекцию сертификатов, люди уходят в тепленький инхауз сидеть на одном месте, под одним ПМ, без авралов, бесконечных командировок и простоев. Таких случаев мне известно на столько много, что я даже полагал что это тенденция. Разве не так?
>> Если компания, условно говоря, торгует пончиками, но при этом разрабатывает и внедряет ERP лучше профессионалов, то почему бы ей помимо торговли пончиками еще и на этом рынке не зарабатывать?
Для того чтобы внедрить ERP и продать ее требуются совершенно разные квалификации. Нет?
В описанном мною случае привлечение внешнего ресурса не повлекло за собой сброс внутреннего. Внутренний был использован для реализации переинтеграции всего со всем и для стабилизации постинтеграциионных флуктуаций. Более того, на проект пришлось нанять еще целое подразделение. Внутренний штат айти распух втрое. Бизнесу, для работы в новой системе пришлось тоже существенно расширять кадры, после внедрения, для управления теми же процессами, потребовался существенно больший штат.
>> Это довольно просто посчитать.
У нас разработчиков — по пальцам перечесть. Точно не знаю их числа, разрабы размазаны по подразделениям и регионам. И мне кажется это большое заблуждение, что для разработки собственной ERP требуется большое количество людей. Здесь решает квалификация. А при поддержке покупного, все равно нужен кто-то достаточно квалифицированный, кто будет осуществлять функции третьей линии поддержки, или же кто способен дать экспертную оценку адекватности цены доработки запрошенную аутсорсером.
>> Просто инхауз разработка в не-ИТ компании всегда обходится бизнесу дороже и дольше, чем внешнее внедрение, это факт.
Не могу тут спорить. Я не располагаю доступом к финансовой информации. В идеале это действительно должно бы так быть, но во времена кризиса наша компания сбрасывала внешние пассивы, забирала на себя поддержку и развитие, расширяла собственный штат.
>> годовой бюджет
Увы я не допущен к этой информации в своей компании.
>> создание похожей системы с нуля
В нашем случае имело место быть «до основания, а за тем...». Впрочем ранее существовавшая самописка мало кого удовлетворяла, в том числе и замечательный инхауз. Имели место огромные проблемы с масштабированием. Перемены, определенно, были нужны, но цена вопроса оказалась на деле не адекватно велика, это, косвенным образом, признал и тогдашний директорат, признавший проект в целом успешным. Нынешний видит в том внедрении источник всех бед компании. С моей точки зрения, не совсем справедливо.
>> все-таки позволяет заказчикам решать свои проблемы и автоматизировать бизнес
Если в этой фразе использовать «как-то», в качестве характеристики способа решения своих проблем, это будет хорошо сочетаться и с имеющимся у меня опытом.
Проблема в том, что вкладывая не малые деньги в покупную систему, это «как-то», для бизнеса возникает неожиданно.
Пять гребаных лет мы приспосабливались к покупной системе с мировым именем, внедренную с привлечением интегратора с мировым же именем. Три гребаных года из них наши магазины имели проблемы со снабжением, а наши склады были завалены никому не нужной фигней.
Но благодаря этому внедрению, мы поняли многое, многому научились, многого перестали бояться. Она нас не убила, а сделала сильнее. Из этой системы мы извлекли множество замечательных идей, которые нам не приходили в голову раньше. Шаг за шагом, мы откусывали от этой системы кусочек функционала и реализовывали его так, как требуют того наши бизнесс процессы. Благодаря этому внедрению, наш бизнесс понял, какие же в самом деле замечательный у него инхауз.
>>На счет отсылки писем из СУБД — не вижу в этом ничего предосудительного
Поддерживаю. Мои ночные жобы часто шлют мыло о сбоях мне и на вторую линию поддержки. В интрасеть, правда, не во вне.
>>для русского текста желательно использовать 'text/html; charset=«UTF-8»'.
Все мои базы в cp-1251, шлю русский текст преобразуя его в raw:
>>помещение операторов SQL в отдельные процедуры и функции. Какие это дает преимущества?
Действительно интересный вопрос.
Мне доводилось над этим задумываться, когда я видел, как эту практику применяет и сам Oracle corp в некоторых своих решениях. Для каждого модуля они оформляют пакетик, в который выносят все SQLчики. Причем не сказал бы, что эти пакетики действительно повторно используется. Если бы их готовили как API для повторного использования, наверное следовало бы резать не по модулям, а по сущностям. API для работы с товарами, API для работы со складами. Так нет же. Они нарезают их по модулям. Делают пакет для формы ввода накладной, пакет для батча расчета потребности. Оба пакета могут содержать совершенно одинаковые DML, при этом в обоих пакетах нет не реализовано ни грамма логики.
Однако при такой организации оказывается достаточно удобно выявлять зависимости, проводить обратный инжиниринг. Уточнение схемы данных приводит к ревалидации и повредившиеся модули видно сразу, а не в процессе их исполнения, сразу же их можно и подправить, без пересборки приложения. Опять же, самый простой способ стабилизировать план запроса — переписать его, захинтовать. Но ели руководствоваться именно этими тезисами, впору усомниться в целесообразности выноса логики на приложение.
Отчасти. Если мы говорим лишь об штучной инсталляции такой «учетной системы», то вполне закономерно нагрузить ее и кастомным функционалом «планирования». Однако если мы желаем иметь ее множество инсталляций, например в каждом магазине, кои у нас исчисляются десятками, быть может сотнями, то расстановка кастомизированных версий коробочного изделия по существенно увеличивает количество рисков поддержки и обновления такого продукта.
Что касается рисков размазывания функций планирования по бизнес-подразделениям, не моих компетенций дело, но с моей точки зрения это тоже весьма весьма и рискованно.
Если смотреть с этой точки зрения, мне кажется абстрагирование бэк-офиса от фронт-офиса, не такая уж и плохая идея.
>> Если компания нанимает хотя бы 3-4 профессионалов
Я так полагаю, Вы сейчас говорите о случае, когда компания заведомо не имеет в своем штате сильной команды бизнес-технологов и аналитиков. Тогда да, привлечение внешнего ресурса — единственный выход. Но мне кажется естественным, если компания пожелает оставить знание об особенностях протекании своих бизнес-процессов на своей стороне. В этом случае даже привлечение внешнего ресурса не избавляет компанию от необходимости нанимать этих 3-4 профессионалов для аккумулирования опыта. В противном же случае, компания обречена на заключение долгосрочных отношений с подрядчиком, что полностью нивелирует весь профит от «эпизодичности» в потребности такого рода отношений.
>>Короче, я остаюсь при своем мнении, извините.
Я не имею целью Вас переубедить — ни в коем случае. Мне просто интересны Ваши тезисы. Они дополняют сложившуюся у меня картину бытия, побуждают меня к размышлениям.
Мне кажется следует разделить понятия «учетная система» и «система планирования ресурсов». Учетная система просто регестрирует бизнесс-факты, система планирования принимает бизнес-значимые решения на основе этих данных.
Разработка собственной учетной системы действительно может занять огромное количество человеко-лет. Всяческие справочники, реестры, регистры, работа с кассовым оборудованием, сканерами и пр. пр. В индустрии действительно присутствует множество готовых решений, в том числе и коробочных. Использовать внешний ресурс для внедрения подобных систем, интеграции, обучения персонала — очевидное и верное решение, это действительно обойдется многократ дешевле нежели реализация собственными силами.
Однако система планирования — совсем другой разговор. Здесь нет устоявшийся практик, каждый бизнес владеет собственным ноу-хау, который позволяет ему быть более или же менее успешным. Это знание аккумулируется в подразделениями бизнес технологий, постоянно оттачиваетя, уточняется и исправляется бизнес аналитиками. Отдавать эти подразделения на аутсорс — очень большой риск потерять весь бизнес. Реализация же этих технологий, как правило не требует большого количества ресурса. Один — два толковых разработчика с лихвой покроют потребности каждого из контуров (финансового, товарного...) организации весьма внушительных размеров. Для реализации алгоритмов ассортиментного планирования, прогнозирования, расчета потребностей, выбора схемы снабжения, оптимального поставщика, формирования заказов, графика оплат, и пр. пр. не на столько уж и много кодинга требуется. Но эти алгоритмы постоянно уточняются, изменяются, исправляются на протяжении всего цикла жизни предприятия, и использование внешнего ресурса, здесь, оказывается не адекватно дорого. Как я уже говорил, аналитику и технологии во внешний ресурс — не отдашь, а удельная доля работ разработчиков в этих доработках не так уж и велика.
Здесь же представлена свистелка, которая призвана облегчить построение материализованного пути — способа, придуманного чтобы как-то компенсировать недостаток средств работы с иерархическими данными в ранних версиях SQL. Мне кажется было бы разумно, если бы были представлены аргументы использования ее против использвания рекусривных запросов и была бы ограничена область применения предлагаемой методики.
Если вы приводите в пример кадровую политику именно этой организации, смею вас заверить, многие торговцы пончиками, производят куда более тщательный отбор нанимаемого персонала. А привлечение БиТ к проекту вовсе не уберегает заказчика от того, что на проект придет куча сброда, не прижившегося на другом проекте. И это при том, что БиТ, сам по себе, не так уж и плох, и даже хорош.
Почему вдруг нет? Почему квалифицированные кадры должны сосредотачиваться именно в софтверных компаниях? Среди моего окружения я наблюдал достаточно случаев, когда устав от этих бесконечных внедрений, сегодня — здесь, завтра — там, есть проект — живешь, нет — лапу сосешь, но набрав при том себе внушительное резюме, внушительную коллекцию сертификатов, люди уходят в тепленький инхауз сидеть на одном месте, под одним ПМ, без авралов, бесконечных командировок и простоев. Таких случаев мне известно на столько много, что я даже полагал что это тенденция. Разве не так?
>> Если компания, условно говоря, торгует пончиками, но при этом разрабатывает и внедряет ERP лучше профессионалов, то почему бы ей помимо торговли пончиками еще и на этом рынке не зарабатывать?
Для того чтобы внедрить ERP и продать ее требуются совершенно разные квалификации. Нет?
>> Это довольно просто посчитать.
У нас разработчиков — по пальцам перечесть. Точно не знаю их числа, разрабы размазаны по подразделениям и регионам. И мне кажется это большое заблуждение, что для разработки собственной ERP требуется большое количество людей. Здесь решает квалификация. А при поддержке покупного, все равно нужен кто-то достаточно квалифицированный, кто будет осуществлять функции третьей линии поддержки, или же кто способен дать экспертную оценку адекватности цены доработки запрошенную аутсорсером.
>> Просто инхауз разработка в не-ИТ компании всегда обходится бизнесу дороже и дольше, чем внешнее внедрение, это факт.
Не могу тут спорить. Я не располагаю доступом к финансовой информации. В идеале это действительно должно бы так быть, но во времена кризиса наша компания сбрасывала внешние пассивы, забирала на себя поддержку и развитие, расширяла собственный штат.
Увы я не допущен к этой информации в своей компании.
>> создание похожей системы с нуля
В нашем случае имело место быть «до основания, а за тем...». Впрочем ранее существовавшая самописка мало кого удовлетворяла, в том числе и замечательный инхауз. Имели место огромные проблемы с масштабированием. Перемены, определенно, были нужны, но цена вопроса оказалась на деле не адекватно велика, это, косвенным образом, признал и тогдашний директорат, признавший проект в целом успешным. Нынешний видит в том внедрении источник всех бед компании. С моей точки зрения, не совсем справедливо.
>> все-таки позволяет заказчикам решать свои проблемы и автоматизировать бизнес
Если в этой фразе использовать «как-то», в качестве характеристики способа решения своих проблем, это будет хорошо сочетаться и с имеющимся у меня опытом.
Проблема в том, что вкладывая не малые деньги в покупную систему, это «как-то», для бизнеса возникает неожиданно.
Но благодаря этому внедрению, мы поняли многое, многому научились, многого перестали бояться. Она нас не убила, а сделала сильнее. Из этой системы мы извлекли множество замечательных идей, которые нам не приходили в голову раньше. Шаг за шагом, мы откусывали от этой системы кусочек функционала и реализовывали его так, как требуют того наши бизнесс процессы. Благодаря этому внедрению, наш бизнесс понял, какие же в самом деле замечательный у него инхауз.
Поддерживаю. Мои ночные жобы часто шлют мыло о сбоях мне и на вторую линию поддержки. В интрасеть, правда, не во вне.
>>для русского текста желательно использовать 'text/html; charset=«UTF-8»'.
Все мои базы в cp-1251, шлю русский текст преобразуя его в raw:
UTL_SMTP.write_raw_data(l_connection ,UTL_RAW.cast_to_raw( 'Content-Type: text/plain; charset=windows-1251'||crlf ||'Subject:=?windows-1251?Q?'||subject||'?='||crlf ||crlf||message||crlf ) );Я всякий раз ласково поминаю админов, когда подключаюсь к нему по rdp с нового места/новой ОС.
Действительно интересный вопрос.
Мне доводилось над этим задумываться, когда я видел, как эту практику применяет и сам Oracle corp в некоторых своих решениях. Для каждого модуля они оформляют пакетик, в который выносят все SQLчики. Причем не сказал бы, что эти пакетики действительно повторно используется. Если бы их готовили как API для повторного использования, наверное следовало бы резать не по модулям, а по сущностям. API для работы с товарами, API для работы со складами. Так нет же. Они нарезают их по модулям. Делают пакет для формы ввода накладной, пакет для батча расчета потребности. Оба пакета могут содержать совершенно одинаковые DML, при этом в обоих пакетах нет не реализовано ни грамма логики.
Однако при такой организации оказывается достаточно удобно выявлять зависимости, проводить обратный инжиниринг. Уточнение схемы данных приводит к ревалидации и повредившиеся модули видно сразу, а не в процессе их исполнения, сразу же их можно и подправить, без пересборки приложения. Опять же, самый простой способ стабилизировать план запроса — переписать его, захинтовать. Но ели руководствоваться именно этими тезисами, впору усомниться в целесообразности выноса логики на приложение.