IT в России и мире в реалиях мирового кризиса
1,404,823 8,483
 

  alexey_k ( Слушатель )
09 фев 2010 11:37:54

Тред №188302

новая дискуссия Дискуссия  486

Цитата: офисный планктон
Видимо, пропустил.
Очень интересно...



Нашёл, 8 января.


Коллеги,

Поделюсь некоторыми соображениями про «русскую ось» и автоматизацию государственной власти.

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

На мой взгляд, озвученные цели типа «составлять чиновникам документы в Ворде» или «электропочта для государства» являются неправильными. Эти краткосрочные цели лежат на поверхности, и возникают при внешнем осмотре проблемы. Чтобы нам у чиновников автоматизировать? Ах да, электропочта! И под эту постановку подбираются экономические обоснования – дескать, чиновник будет в два раза меньше времени тратить на работу с бумажными документами, следовательно, возрастёт эффективность, а для этого нужна национальная ОС, не буржуям же деньги платить...

Правильной задачей могла бы быть такая постановка: «Обеспечение долгосрочного преимущества социально-экономической системы РФ путём организации и поддержки максимально эффективного управления». И под эту цель разрабатывать решения. Если правильно спроектировать эффекты и результаты от внедрения такой системы, то, полагаю, государству было бы интересно финансировать разработку национального проекта в этой области. Не чтобы сделать ещё одну ОС впику Гейтсу с Торвальдсом, а чтобы обрести эффективную систему гос. управления, и через это получить стратегическое преимущество.

Поэтому, подход к целеполаганию и планированию в этой области должен быть другим. Нужно сформулировать концепцию не «национальной ОС» (блин, какое липучее слово), а национальной платформы поддержки управления. Реализовать такие базовые механизмы, которые позволяли бы на её основе выстраивать управляюще-планирующие информационные системы:
1. Обладающие высокой гибкостью и адаптивностью по объектам внедрения – ведомствам, учреждениям, отраслям, гос. корпорациям. Чтобы не тратить годы-месяцы на внедрение, а, обеспечить быстрое начальное внедрение и механизмы развития системы – либо внутри организации, либо внешней службой, не важно.
2. Обладающие едиными принципами передачи информации (не только протоколами, но, скорее, логической архитектурой), позволяющими масштабировать управление от цеха до совокупной экономики страны.
3. Поддерживающие все необходимые операции по сбору и предоставлению информации, в рамках информационных процессов, входящих в состав системы управления. Т.е. не вводить документы, чтобы их печатать и отправлять по почте, и не заполнять электронные заявки, чтобы их читал секретарь на мониторе, после чего следует обычный порядок исполнения. Вместо этого ввод информации и документов должен производиться, в первую очередь, как «первички» для контроля и планирования – а во вторую, для управляемой коммуникации (например, по процессам-регламентам, включая население).

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

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


А что нужно, чтобы это сделать? Нужен ли национальный линукс на ядре собственной сборки, или нужно что-то другое?
Конечно, «другое». Речь правильно вести о платформе поддержки управления, и разрабатывать её функциональность исходя из стоящих задач. Что в неё должно входить?
1. Система, позволяющая быстро моделировать предметные области, и быстро получать по моделям работающие управляющие приложения. В состав приложений входит работа с информацией (предоставление и ввод), организация регламентов-процессов, сбор отчётов-показателей как замыкание управленческого контура (собираем первичку => агрегируем показатели у начальства => управленческими пинками корректируем исполнителей). Пусть она даёт работать с текстами и формировать документы, раз на этом держится документооборот. Отдельная служба будет следить за показателями использования системы и быстро корректировать модели. Со временем реакции не больше суток на заявку.

Такая штука позволит закрыть процентов 80 текущих задач ведомств.

2. На следующем этапе, вводятся средства планирования и прогнозирования показателей развития, а также интеграции данных отраслевых-ведомственных систем на более крупных уровнях. Это даст глобальный взгляд на уже имеющуюся первичку, позволит выявлять узкие места в экономике и эффективно распределять ресурсы. Плюс, публикация проектов и потребностей для того. Чтобы субъекты экономики могли самостоятельно участвовать в решении актуальных задач экономики.
3. На третьем этапе, подключаются средства автоматического анализа стратегий – с целью поиска глобального оптимума деятельности экономических субъектов. Здесь, конечно, начинает быть похоже на ИИ и прочие методы, однако, уверен, это всё вполне реалистично (причём быстро). В результате система будет не только выявлять узкие участки, но и предлагать решения, и рекомендовать стратегии субъектам экономике, которым им следует применять для совокупной (обоюдной для себя и всех остальных) выгоды.

Нужно ли для такой системы делать «национальную ОС»? Можно, но не в первую очередь. Я бы предложил проект архитектурно делать на базе веб-технологий – т.е. логика обработки информации и математика обрабатываются на сервере (точнее, системе связанных серверов), доступ к которому осуществляется через обычный браузер.

Тогда:
1. На клиентских местах в смысле ОС может стоять что угодно. Можно поставить Альт-Линукс. Можно поставить МСВС с открытым браузером FireFox. Можно сделать собственную «нетбучную» сборку, чтобы была файловая система и загрузчик, способный стартануть тот же FireFox. Более того, нетребовательность клиентских мест к аппаратуре даёт возможность использовать без ущерба даже чисто российское железо, если это важно (ну, все видели картинку ноута с процессором Эльбрус 500 MHz).
2. На сервере должна стоять такая ОС, на которой будет работать Платформа. Это может быть Windows, сборка Линукса, серверный вариант МСВС или всё, что угодно. Лишь бы работала Платформа. Аппаратно, кстати, наверняка можно припахать что-нибудь типа российского СКИФа.

Причём, на мой взгляд, всё это можно осуществить довольно быстро и поэтапно.

Примерно так.Крутой
Отредактировано: alexey_k - 09 фев 2010 11:40:21
  • +0.04 / 4
  • АУ
ОТВЕТЫ (8)
 
 
  офисный планктон ( Слушатель )
09 фев 2010 11:57:45

Спасибо!
Четыре нескромных вопроса:
1) есть ли у Вас опыт работы (автоматизация процессов, построение сети, организация БД) с ведомствами и/или гос аппаратом, скажем, области?
2) какие основные проблемы, при этом, хотели решить чиновники (например, самый главный)?
3) какие основные проблемы у Вас были, при выполнении проекта?
4) совпадало ли Ваше представление о задачах с представлением постановщика задач?
  • +0.00 / 0
  • АУ
 
 
  alexey_k ( Слушатель )
09 фев 2010 12:17:05


1. Разовый опыт работы с ведомствами есть (региональное управление федерального ведомства).
2. Документооборот, учётно-отчётные задачи.
3. Погружение в достаточно специфичную предметную область, плюс война с собственной платформой.Улыбающийся Впрочем, последнее на заказчике не сильно отражалось.
4. Общались непосредственно с заказчиком, минуя "постановщика".

Позвольте нескромный вопрос, а почему Вы спрашиваете?Подмигивающий

зы. Я понимаю, что до спроса на системы управления наши ведомства, особенно региональные, категорически не дозрели. Но речь идёт, в общем-то, не об их желаниях.
  • +0.18 / 2
  • АУ
 
 
 
  офисный планктон ( Слушатель )
09 фев 2010 13:19:48

Вопросы потому, что хочу сверить впечатления.
Отвечу за себя.
1) У меня опыт в IT небольшой, прямо скажу. Автоматизация -это маленькая веточка работы моей компании. Что мы делали - автоматизация работы диспетчерской службы 112 и оперативного штаба ЧС крупного города. Диспетчерские скорой помощи крупных и мелких городов. Автоматизация учета расхода элэнергии крупного города (я лично, в этом проекте  не участвовал). И дальше, по-мелочам.  Ведомственных и корпоративных сетей же строил немеряно, самых разных и в самых разных странах. Операторских - существенно меньше. (Не сочтите за саморекламу, просто, что б понятно было с кем говорите).
2) Чиновники. В РФ. В основном, выделиться. Далее, как ни странно, профессиональный интерес (сильно ограничивается нежеланием рисковать, что, впрочем и неплохо... они же, чиновники, все еще и профессию какую нибудь имеют, кроме того, что руководят...). Затем, деньги.
3) Не желание заказчика (его представителей) вникать.
4) Как правило, совпадало (в той части, что я помогал ему решить п.2). Но мы задачу, тем не менее, ставим шире. Кроме зарабатывания денег (мы ж комерсы), мы (Вы будете смеяться) самореализуемся. Это же все жутко интересно. И за чужой счет. К тому же, этим можно как то гордиться, что ли. Потому как польза...

PS Я уже говорил ранее, но решил, что будет уместно повторить. Любое начальство начинает оч шустро соображать, когда есть угроза  власти. Никто, пока не озвучил, что недостаточное развитие IT несет эту угрозу в рамках государства.... И  уж, тем более, не обосновал почему... Или я пропустил.
  • +0.27 / 1
  • АУ
 
 
 
 
  alexey_k ( Слушатель )
09 фев 2010 13:32:59


Спасибо, понял.

Видите ли, в чём дело. Смотрим цель, которую я обозначил в своём посте: "Обеспечение долгосрочного преимущества социально-экономической системы РФ путём организации и поддержки максимально эффективного управления". Можно ли её достичь путём спуска вниз правильной федеральной программы, с созданием технологйи и принятием регламентов? Очевидно, да. Можно ли её достичь путём низовой автоматизации ведомств? Очевидно, нет, т.к. мы будем решать лишь текущие задачи.

Есть ли ещё путь достижения этой задачи? Да, это выпуск коммерческого продукта для коммерческих компаний. Обеспечивающий эффективность локального управления и автоматизации, но при этом способствующий их синергетическому взаимодействию - вплоть до построения здоровенных скоординированных производственных сетей, рассчитывающих и согласующих стратегии для всех вместе и каждого в отдельности. Фантастика? Пока да. Нужно ли сюда двигаться? Безусловно да. Если государство проснётся, то уже будут технологические и практические наработки. Если нет - дотянемся и так.
  • +0.00 / 0
  • АУ
 
 
 
 
  wellx ( Слушатель )
09 фев 2010 20:55:03

Я постоянно это пишу, мож, как-то непонятно пишу?
  • +0.00 / 0
  • АУ
 
  Поверонов ( Слушатель )
12 июн 2010 18:31:09

ПМСМ в приведенной цитате самое конструктивное предложение в этой теме.
К сожалению, интересная тема явно затухает, придётся подбросить дровишек.
Сначала приведу некоторые размышлизмы, всплывшие по ходу чтения данной дисскуссии.
Об ОСи. Почти бесплатное продвижение мелкомягкой платформы в госорганы проводится, конечно, не без умысла.  Все наверное догадываются, что экспортируемое оружие в самого экспортёра не стреляет. Как уж они закладки встраивают и обновляют, это их ноу-хау.  И понятно, что никакие запечатанные бинарники ничего гарантировать не могут пока приходится их гонять на забугорном процессоре. Какие недокументированные команды в этот камень вшиты и как они запускаются их ОСью, мы может и узнаем, но только во время Ч. ФСБ разумеется это понимает, но пока не будет своих процессоров, многого изменить не может. Для того и закупают старые линии, что-бы самые важные дыры хоть чем-то заткнуть. России свои процессоры жизненно необходимы и прежде всего для встроенных и серверных систем. Вот на своих камнях и матплатах может будет безопасно гонять и запечатанные ОСи,  а для забугорных процессоров надо писать свою ОСь и чем радикальней она будет отличаться от известных, тем будет лучше для выживания окружающих .
С идеей национальной платформы приведенной в цитате, в основном, согласен. Творить  в первую очередь нужно, конечно, не ОСь, а  многоуровневую систему протоколов, обеспечивающих распределенный документооборот на базе открытых стандартов типа OpenDoc. Нечто вроде внутреннего интернета, где OpenDoc вместо HTML, собственные справочники вместо ICANN,  SOA вместо GET/POST, OpenSource вместо проприетарных M$.
Закодировать сервисы на базе продуманной системы протоколов не так уж сложно. На классике LAMP +SOA можно создавать вполне рабочие сервисы, а на оконечниках достаточно браузеров под аяксом.
Но сделать весь основной задел можно только на энтузиазме и бесплатно. И надо бросить решать первую российскую проблему и оставить госаппарат на распилке его собственных затей. У них для этого академики есть, а после них кроме опилок там ловить нечего.
В качестве области приложения посоветовал бы заняться известной второй российской проблемой - дорогами, сначала железными, а затем и остальными, т.е. транспортной логистикой. Почему ? Во-первых,  они всегда платежеспособны и если почувствуют эффект, смогут хоть что-то оплатить, во-вторых - это огромный  пространственный плацдарм от Смоленска до Владивостока, где смогут пастись тысячи консультантов-внедряльщиков, проникающих во все смежные грузоперевалки,  как-то автотранспортные, речные и морские порты, ну а там по рельсам можно переползать и заграницу - в Европу и Китай вплоть до ... Нью-Васюков.
Навскидку можно назвать несколько уровней для системы протоколов в порядке снизу-вверх:
1. Хранение и выборка.
2. Идентификация и адресация.
3. Роли и полномочия.
4. Маршрутизация и доставка.
5. Фильтрация и конвертация.
6. Отчетность и статистика.
7. Манипуляция и визуализация.
Некоторые видимые требования к такой системе. Все тэги в протоколах, документация и прочее намеренно должны быть только русско-язычными, во-первых, для самих творить легче, во-вторых, супостату будет крайне затруднительно этот OpenSource слямзить, в-третьих, в случае успеха и распространения это даст работу многим бывшим соотечественникам, что тоже невредно. В протоколы сразу должны быть встроены пооперационные начисления оплаты через счета WebMoney и аналогичные, тогда и независимым провайдерам будет интересно поставить к себе какой-нибудь сервер, если с него автоматом можно будет зарабатывать. Также в протоколы нужно встроить резервирование и мониторинг. Развитие протоколов должно быть только преемственным, так чтобы сервисы не теряли способность исполнения прежних версий протокола наряду с новой версией.
Чтобы начать делать, надо собрать десяток гуру - по одному на уровень и двух-трёх  межуровневых, а к ним по два-три помощника, которые должны перелопачивать интернет и заваливать гуру подходящей инфой. Нужен subversion сервер желательно с зеркалами для накопления результатов. Когда что-то забрезжит,  можно привлечь студентов, аспирантов или преподавателей из профильных вузов, желательно имеющих ведомственные корни.
Думаю года за два можно собрать макет из десятка сервисов на которых уже можно проводить демонстрации и обучение.
  • +0.00 / 0
  • АУ
 
 
  mrt789 ( Слушатель )
28 июн 2010 00:01:32

У вас в голове каша, не подскажете как SOA (сервис-ориентированная архитектура) может заменить HTTP-методы GET и POST? Более того, даже если предположить, что вы описались и подразумевали SOAP, то все равно не понятно... противопоставлять вышестоящий протокол (SOAP) нижележащему (HTTP) бессмысленно, SOAP от HTTP не зависит.


Сервис-оринетированная архитектура на похапе? Или таки опять имеются в виду SOAP-сервисы? Но позвольте, не одного нормального движка веб-сервисов (уровня WCF/Metro) на похапе как бы нет и никогда не было. Или я таки ошибаюсь?



1. СУБД (возможно для удобства представленные в виде SOAP или REST сервисов)
2,3. WS-Security, WS-Federation и пр.
4,5. ESB/MOM'ы (с BPEL/XSLT и другуми обработчиками внутри, гарантированной доставкой и пр.).
6. Систему мониторинга придется скорее всего делать специальную.
7. HTML/CSS/JS на клиенте, REST c JSON'ом на сервере + отдельный SOAP/REST API, для взаимодействия с други программными системами (в том числе, с альтерантивным клиентами).
+
Стандартизованные схемы для XML документов.

Это все уже давно придуманно, хотя пока и существует в довольно фрагментированном виде. Более того, есть, например, CommerceML разработанный для B2B взаимодействия и встроенные в каждую 1С'ку, причем кое-где он даже используются, да и всевозможные EDI'ии, опять же...

Но незнание технических тонкостей - это не страшно. Главные вопросы, которые я бы вам задал:
1. Кто главные выгодоприобретатели от предлагаемой вами системы (и в чем будет их выгода, и нужна ли им она, или это вы лежа на диване за них подумали)?
2. Кто будет заниматься стандартизацией?
3. Кто способен занятся ее реализацией?
4. Какие гарантии должна предоставлять такая инфрастркутра своим участникам? Как быть с коммерческой тайной? Возможно ли несколькми участниками поднять параллельную инфраструктуру, изолированную от общенациональной?

И вот от ответов на эти вопросы зависит практически все. Я бы сказал, именно они определяют, что получится на выходе: очередной ЕГАИС или же нечто жизнеспособное.
  • +0.00 / 0
  • АУ
 
 
 
  Поверонов ( Слушатель )
02 июл 2010 00:59:23
Не хотелось бы ввязываться в терминологические дискуссии, определения зависят от учебников, по которым они воспроизводятся. Собственно хотелось просто минимумом слов вызвать некоторые профессиональные ассоциации, и судя по Вашей реакции, это получилось. Но на вопросы считаю нужным отвечать.  


"Архитектура веб-сервисов является одной из реализаций SOA. Понятие архитектуры, ориентированной на сервисы, сложилось в ходе развития концепции веб-сервисов. Однако, существуют и другие походы к реализации SOA: Java RMI (от Sun Microsystems), CORBA (от консорциума OMG), DCOM (от Microsoft), DCE (предложенный ассоциацией Open Group)."
см. http://xmlhack.ru/te…vices.html
«Writing SMTP-Based SOAP Messages in PHP»
http://www.drdobbs.c…4ATMY32JVN



Действительно, сильно развитыми эти фреймвоки не назовешь:
http://sourceforge.net/projects/nusoap/
http://wso2.org/library/3411#solution
http://framework.zen….soap.html
http://developer.app…apphp.html
но кое-что есть, от чего при желании можно отталкиваться. Собственно речь должна идти о разработке собственного «движка». PHP упомянут как известный OpenSource c обширной и также открытой библиотекой с достаточной производительностью. Остальные кандидаты java или .net  являются проприетарными или полностью или в части библиотек, а тащить хвост лицензионных проблем было бы опрометчиво.


Речь и идёт о том, чтобы собрать уже известные фрагменты в один «движок», дописав недостающие связки.


Во-первых, «выгодоприобретателями» могут стать те средние предприятия, для которых внедрение «электронного» документооборота не игрушка для «освоения» бюджета, а путь к снижению потерь, простоев и повышению производительности, но которым SAP не по доходам.
Во-вторых, те малые IT-предприятия и/или фрилансеры, которые смогут на базе этого «движка» внедрять и поддерживать такой документооборот на этих предприятиях. Выгода для обеих сторон в том, что на этапе внедрения оплачиваются только трудозатраты «внедрителей», так как сам продукт условно бесплатен. Собственно оплата продукта производится на этапе поддержки как бы в рассрочку, когда предприятие оплачивает пользование реальной системой. В процессе пользования системой оплата начисляется как в пользу «внедрителя», так и разработчиков.



Некая ассоциация разработчиков-добровольцев, координируемая избранным правлением.


Та же ассоциация.


Вопрос не понятен в свете наличия разного рода «участников».
Предприятие-пользователь получает и ежемесячно оплачивает постоянную поддержку от предприятия-внедрителя, гарантированную контрактом. Ассоциация-разработчик также является соучастником контракта и подстраховывает пользователя на случай банкротства «внедрителя».
Предприятие-внедритель использует наработки ассоциации по лицензии, за которую вносит плату ассоциации.
Разработчики получают отсроченную оплату трудового вклада в разработку.


Никакая IT-инфраструктура не способствует сохранению тайн, так как вовлекает некоторое число специалистов:  сисадминов, разработчиков, которые постоянно или эпизодически в аварийных ситуациях могут получить вольный или невольный доступ к оберегаемым данным. Как известно, защиты от root не существует. К тому же такие специалисты имеют склонность и возможности часто менять место работы. Поэтому особо конфиденциальные документы просто должны оставаться в бумажном контуре и не вводиться в «электронный», а храниться в сейфах. Что касается ограничения доступа посторонних лиц к документам предприятия при транспортировке их публичными сервисами, то по-видимому,  транспортный протокол должен обеспечивать доставку «контейнеров», содержащих закодированные документы, понятные только адресату на основе обмена открытыми ключами.
Если Вы имеете в виду раскрытие коммерческой тайны пользователя в процессе обследования его деятельности сотрудниками предприятия «внедрителя», то здесь ситуация не лучше и не хуже, чем при любом внешнем аудите, проводимом налоговой или любой другой инспекцией. Если успех коммерческой деятельности предприятия базируется на тайне, то пусть оно развивает успех без привлечения IT. Интересно, а куда  они девают уволившихся работников, а также всякого рода инспекторов ?



В исключительных случаях, наверное, возможно, так как проконтролировать скрываемое внедрение нет возможности. Но это должно быть крайне невыгодно, так как придётся развертывать приватные сервисы вместо использования публичных. Кроме того такое предприятие останется навеки изолированным от других предприятий и должно будет «общаться» с ними только по «бумажной» технологии.
  • +0.00 / 0
  • АУ
 
<< Тред №188301
Тред №188303 >>