Pull to refresh
-30
Дмитрий@vde69read⁠-⁠only

User

Send message

Ни когда не переваривал автора данного опуса (и как человека и как специалиста), но тут в его словах есть определенная доля правды.

Начиналось на Мисте весело и задорно, но с какого-то момента я перестал понимать действия (и мотивации) С. Митичкина, от слова совсем. В тот момент я решил для себя очень просто - его форум, чего хочет то и делает, он делает чего хочет. Одно время я думал, что он ставит на мисте какой-то социальный эксперимент (например для чье-то дисертации или научной работы), на столько странно выглядили его действия, но я никогда с ним не пытался спорить (это просто глупо на его форуме).

На мой взгляд это его дело, часть "стариков" уходит, часть "молодежи" приходит и это не должно привести к совсем уж краху.

А вот настоящий крах о чем я сожалею, постиг всем известный sql.ru и вроде-бы не из-за снижения посещаемости а по политической воли владельца.

И вот тут Автор данного поста безусловно прав - если форумом владеет частное лицо, то он может в любой момент сдохнуть, и миста не исключение.

Это относится к исполнителям (к программистам), но никак не к аналитикам. Банально если человек уверен, что он точно знает что именное ему нужно он никогда не пойдет к аналитику...

Ну и до кучи - никогда не думайте, что Вы знаете лучше остальных, что им нужно...

Поставил плюсик, в целом описано много чего реального (хотя есть и явные минусы).

Но кратко суть бизнес аналитика в 5 пунктах

  1. Уметь описать как есть сейчас (включая графики в нотациях, я из всех нотаций предпочитаю idef-0)

  2. Заставить колектив самому понять слабые места у текущей схемы

  3. Описать как будет (так-же "красиво")

  4. Заставить колектив самому придумать шаги которые должны привесть пункт 1 к пункту 3

  5. Описать придуманые в 4 шаги в некий стройный план (включая диаграмму ганта)

Суть этого в том, что-бы решение родилось в коллективе а не в твоей голове, тем самым ты избежишь саботажа и в случае провала снимешь с себя ответственность.

Сэкономили 30тр в месяц, а сколько потеряли за счет снижения эфективности работы пользователей? Уверяю, что гораздо больше... ЗП одного хомячка в офисе раза в 3 выше....

Кроме того Вы получили риски уйти в жесткий отказ в случае пиковых нагрузок (а такие нагрузки как правило периодические, например начали считать зп в 1с).

Ну и на сладкое как всегда риски ухода памяти в своп и отказ сервиса. Много раз видел при подобных оптимизациях.

честно не понял какая может быть дефрагментация в век когда везде ставят SSD...

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

а вот про динамическое выделение ресурсов могли-бы и поподробнее написать

Из личного опыта:

если оперативки занято 80% или ЦП сумарно загружен на 80% - надо СРОЧНО бежать в магазин докупать ресурсы...

У этого решения есть существенный недостаток. Это скорость работы.

Дело в том, что оперативный учет который критичен к оперативности данных ведется в своих модулях и его не требуется перегружать из базы в базу вообще. Перегрузка требуется для отражения консолидированных (укрупненных) данных (да хоть в тот-же би ай) но там нужны не сырые данные а итоговые и сильно укрупненные, в результате их количество сильно уменьшается.

Ну и потом не забываем про MDM, для больших компаний именно НСИ является основой обменов, а программ MDM на рынке явно больше одной и они очень прилично оптимизированы на скорость обменов.

Ну и напоследок есть так называемые бесшовные интеграции (например 1с:Документооборот), где все обмены реализованы на rest запросах и обменов в привычном понимании как таковых нет вообще, там все в реальном времени проходит.

По этому скорость обменов, как критерий для выбора архитектуры, сейчас сильно устарел...

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

Начнем с того, что основной идеей внедрения SAP всегда была капитализация на биржевых рынках, присвоения всяких индексов и выпуск акций. Ни какого реально учета в SAP ни один нормальный бизнесмен в России не будет вести (причина простая, система очень консервативная, что-то написать свое в ней это огромные деньги и куча времени). По этому действительно в параллельно SAP учет велся в более простых и понятных местному бизнесу системах.

Теперь про идеологию ЕРП - она предполагает вести почти все в одном монстре. Да такой подход имеет право на жизнь, но точно так-же можно вести отдельно финансовый учет в своей программе, товарно складской в своей, кадровый в своей и все это связать едиными центрами MDM и тд, такой подход то-же имеет право на жизнь. К примеру сколько разных информационных систем в банке ВТБ (уверен гораздо больше десятка)? А что будет если все свести в одну базу? Ничего хорошего не будет, по тому как есть фронт офис и бек офис а еще билинг и все они ну никак не совместимы в одной системе.

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

Но сейчас автор оказался явно не в тренде, сейчас все компании стали пилить ИИ, и там вообще беспредел, так как четких рамок, что именно является ИИ в мире не существует и это дает возможность вешать лапшу прямо от ушей до пола.

А до ИИ было НАНО...

А потом будет Кванты...

И так бесконечно...

Ну а нам остается только пытаться не вляпаться в совсем уж грязные "плюшки"....


Что-бы было понятно сразу - я начинал с try языков, и только потом меня прибило в 1с (хотя и сейчас иногда как хобби балуюсь и с++ и php), по этому у меня есть как внутренее так и внешнее понимание, последние 20 лет я тимлидер/архитектор/аналитик и тд, то есть к проблеммам внедрения имею самое прямое отношение.

По поводу платформы 1с - она очень крутая (особенно по скорости разработки), не смотря на некую костность конкурентов у нее нет, ни какой SAP даже близко к ней не подходит сейчас.

В 2013 году я публиковал свое видение проблемных мест в 1с, кому интересно могут найти... За это время компания 1с избавилась от большинства проблем которые я тогда озвучивал (это говорит, о том, что 1с не стоит на месте а развивается)

Теперь давайте разберемся в сильных и слабых сторонах компании 1с (не платформы)

У 1с есть 3 кита на которых она стоит

  1. Самое сильная сторона это огромная сеть франчай, ни один из вендоров не имеет такого количества в России никто, даже близко нет конкурентов

  2. Огромный штат исполнителей (кратко 1с ников) в России, их целая армия, тут то-же в России 1с явно на первом месте

  3. Привычка для пользователей, не так много пользователей компьютеров которые хотя-бы изредка не используют 1с

Теперь слабые стороны

  1. Самая слабая сторона это возраст собствеников, и по сколько именно они на 100% руководят компанией, то рано или поздно 1с столкнется с гигантским кризисом когда они уже не смогут это делать (дай бог им здоровья)

  2. Увлечения некими ультамодные теченими, вроде мобильного клиента или 1с:Элемент. Собственно увлекатся новым стоит, но всегда с оглядкой, и чаще всего стоит делать новый продукт а гипер мутант. Вот пример с их ФРЕШ, да эта модель ведения бизнеса безусловно имеет свои плюсы, но на мой взгляд ее стоило выпустить совсем отдельным продуктом а не как сейчас интегрировав ядро управления во все типовые конфигурации.

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

Information

Rating
Does not participate
Registered
Activity

Specialization

Архитектор 1С
Ведущий