Про разработку информационных систем…

[Nadir Zaitov]

Сегодня как в кашмарном сне в очередной раз перечитываю "документы", ранее "подготовленные" для реализации IT проекта, с которым я работаю. Я вполне нормальный чайник в IT бизнесе, однако и мне страшно видеть, как можно "не уметь" работать и готовить документы. Невольно вспомнил топик в баш.орге, который сразу начал упорно искать и отыскал:
c форума sql.ru про разработку информационных систем…

…А вообще, я очень хочу, чтобы наша профессия со временем стала такой же инженерной дисциплиной, как, например, строительство - вам нужно здание? Извольте заплатить за проект, а потом за возведение, или покупайте (арендуйте) готовое, но тут уж не выдвигайте требований пристроить к нему еще 30 этажей. Изволили построить времянку, а теперь хотите ее превратить в доменный цех? нет проблем - СНОСИМ временку и строим цех. Через пять лет вам потребуется переделать цех в аэропорт? Это ваши трудности - х*й в голове медицина бессильна. Вы никогда не задумывались почему в IT такой процент проваленных проектов (представьте себе такой процент например в автомобилестроениии)? А потому, что делают их не в рамках инженерного подхода, а вопреки ему…. И заметьте, никто не кричит “Судостроители пи…сы не хотят переделать речной трамвайчик в ледокол”. Ээээх мечты…


Так вот и мой вопрос: кто знает статистику по проценту проваленных IT проектов в Узбекистане? В госсекторе? В частном секторе? Может кто-нибудь подетится своим опытом, то было бы интересно.

[Erkin Kuchkarov]

Cегодня как в кашмарном сне в очередной раз перечитываю "документы", ранее "подготовленные" для реализации IT проекта
Это практически каждый день у нас
кто знает статистику по проценту проваленных IT проектов в Узбекистане? В госсекторе? В частном секторе?
Тот кто ее ведет, а ведет ее "никто" - у них и спрашивайте :)

[Eldar Fattakhov]

кто знает статистику по проценту проваленных IT проектов в Узбекистане?
Здесь лучше будет озвучить количество разваленных (и не реализованных в итоге) проектов... :(
Хочется думать (базируясь на отсутствии у меня отрицательных данных по проектам на основе технологий HP), что таковых нет. Большинство проваленных проектов с компьютерной техникой не являются ИТ-проектами, так как предусматривали только оснащение рабочих мест (например, поставки в МНО и МВиССО).

[Nadir Zaitov]

Хочется думать (базируясь на отсутствии у меня отрицательных данных по проектам на основе технологий HP), что таковых нет. Одно дело исправно поставить оборудование (и я уверен мало-мальски уважающий себя вендор сделает все, чтобы его так и поставить! :)). Идя в том, чтобы оно потом работало и именно так, как задумывалось. Вспомните те же школы, в которых компьютеры просто заперты от детей чтоб не испортились, или те же компьютеры в школах, которые используются детьми для "контры" во время уроков. ИМХО, оборудование работает не значит, что оно выполняет свою функцию.
Это практически каждый день у нас Поделитесь типичными ошибками и как Вы с ними управляетесь, плс. Запарился с обчными проблемами, на которые нарываешься на своем опыте. Хотелось бы увидеть как их предупредить :)

[Eldar Fattakhov]

чтобы оно потом работало и именно так, как задумывалось.
Я - про то же. Поэтому о проектах говорил именно в этом аспекте "чтобы работало так, как задумано". Если заказчик не блокирует наши (HP) попытки помочь ввести систему в эксплуатацию, то проект доходит до положительного результата (как минимум - для заказчика). :)

[Nadir Zaitov]

проект доходит до положительного результата (как минимум - для заказчика) Это игра слов? "проект дошел до заказчика" - наконец заказчик понял, что хотел от него поставщик :)!

[Eldar Fattakhov]

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

Если это - игра слов, то возможен и второй вариант: до поставщика наконец дошло, что именно хотел заказчик! :)

[Erkin Kuchkarov]

Поделитесь типичными ошибками и как Вы с ними управляетесь, плс. Запарился с обчными проблемами, на которые нарываешься на своем опыте. Хотелось бы увидеть как их предупредить
Охотно
1. Все требования формируются в результате предварительного обследования и однозначно выражаются в техническом задании
2. Весь процесс внедрения проводится в четком соотвествии с согласованным и утвержденным техническим заданием, календарным планом
3. Любое изменение функционала или требований к АС только после проведения испытаний на соответствие действующему ТЗ и сдачи проекта в опытную эксплуатацию, на основании дополнительного соглашения и обязательно дополнительных денежек.

[Nadir Zaitov]

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

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

2) Другой пример ляпа, который не сразу увидешь. Персональный компьютер (по спецификации такой домой покупать западло) вдруг иногда называется рабочей станцией и требуются документы, подтверждающие, что это рабочая станция! Загрузка писюка - веб-браузер как максимум, а подавай рабочую станцию - просто нашелся умник красивое слово вставить. Убили бы меня, если я не прав и рабочая станция и персоналка - это абсолютно одно и то же?

3) Выяснилось, что люди не представляют, ЧТО ТАКОЕ растаможка и какие документы и в каком количестве нужны... думаю что делать - за...думался до дыр в мыслях! Решил просто с Вами, ребята, пообщаться пока дыры сами залатаются (с подсознанием распараллелился :)).

[Erkin Kuchkarov]

с подсознанием распараллелился
Так..... скоро тендер намечается? ;)

[Nadir Zaitov]

Так..... скоро тендер намечается? Когда наметится, тогда объявится ;) Могу продублировать приглашение тут ;)

[Erkin Kuchkarov]

Когда наметится, тогда объявится Могу продублировать приглашение тут
Уж извольте :) Может и нам перепадет работенка.

[Vsevolod Usmanov]

Поделитесь типичными ошибками и как Вы с ними управляетесь, плс. Запарился с обчными проблемами, на которые нарываешься на своем опыте. Хотелось бы увидеть как их предупредить
Охотно
1. Все требования формируются в результате предварительного обследования и однозначно выражаются в техническом задании
2. Весь процесс внедрения проводится в четком соотвествии с согласованным и утвержденным техническим заданием, календарным планом
3. Любое изменение функционала или требований к АС только после проведения испытаний на соответствие действующему ТЗ и сдачи проекта в опытную эксплуатацию, на основании дополнительного соглашения и обязательно дополнительных денежек.
Завидую Вам “белой завистью”. Реализовать проект по такой схеме – большое искусство как аналитиков, разработчиков и менеджеров проекта, так и проектной рабочей группы заказчика (особенно, если обошлось без допсоглашений и дополнительных денежных инъекций). Ни разу не только не участвовал, но и не видел (можно сказать, что плохо смотрел :)) проекта по разработке заказной информационной системы, где бы предокончательный вариант системы (сданной в опытную эксплуатацию) полностью совпадал бы с требованиями, четко и однозначно, определенными в утвержденном техническом задании, которое не претерпело никаких изменений со дня утверждения. Может быть за исключением проектов, где техническое задание (не в стандарте ГОСТ34 или ГОСТ19) подготавливала одна компания, а реализовывала другая компания.

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

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

Даже несовершенный в современных реалиях стандарт ГОСТ34.602-809 (Техническое задание на создание АС) допускает изменения к ТЗ на стадии разработки и запрещает изменения на стадии приема-сдачи.

1.7. Изменения к ТЗ на АС оформляют дополнением или подписанным заказчиком и разработчиком протоколом. Дополнение или указанный протокол являются неотъемлемой частью ТЗ на АС. На титульном листе ТЗ на АС должна быть запись «Действует с ... ».
...
11. Изменения к ТЗ на АС не допускается утверждать после представления системы для ее очереди на приемо-сдаточные испытания.

[Erkin Kuchkarov]

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

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

Если на этом этапе все сделано и удовлетворяет требованиям Заказчика к проектируемой системе (то есть полностью отвечает его ожиданиям и удовлетворяет его потребностям) то о каком изменении может идти чем речь?

[Alexander Kuznetsov]

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

В том-то и дело, что когда имеется ТЗ и план-график, то это выгодно не только разработчику но и заказчику, т.к. он всегда знает с кого и что спросить. И проект в этом случае (в случае грамотного ТЗ) не будет не укладываться в сроки и не потребует никаких дополнительных затрат.

[Gebo]

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

[kdima71]

Всем привет!

Однажды я прочитал эту книгу (http://microsat.sm.bmstu.ru/e-library/Books/DeathMarch_rus/Death.doc)....долго думал!


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

[Nadir Zaitov]

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

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

[Erkin Kuchkarov]

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

[Erkin Kuchkarov]

Например, вопрос "сколько должна стоить "малёханькая" доработка" упирается в такой конфликт интересов, который в Италии закончился бы пулей в голову
Надир - Вы это... людей то не пугайте. Давайте на банальных, общепонятных примерах
1. ТЗ на ИТ инфраструктуру для СУБД.. в ТЗ порешили что сервак, к примеру, имеет большую, достаточную, дисковую подсистему (DAS)
Много памяти, много процессоров. 4 езернет контроллера, RAID офигенный, ОС Windows 2003 R2 Std, СУБД SQL 2005 Std. (ИОПсы, террафлопы - все подсчитали по какой нить формуле или взяли из сайзера производителя... не в этом дело). Зашибись? Подписали.
3. Процесс закупки и доставки прошел как нельзя лучше - железку отгрузили, расстаможили, собрали... тут и лицензии подошли (конвертик)
2. В процессе интеграции и миграции у заказчика появились\сформировались новые требования - нужен отказоустойчивый кластер.
Заказчик согласен пересмотреть условия ТЗ. Готов подписать допу без
увеличения стоимости - буквально слезно просит бамажку.
Ну и как Вы, интегратор, поступите? ;)

[Eldar Fattakhov]

Ну и как Вы, интегратор, поступите?
Зачастую у заказчика стоит проблема, сформированная ВЫШЕ инфраструктурного уровня (на стыке приложения и ИТ-инфраструктуры): недостатки прикладного пакета или недостаточный уровень оптимизации ИТ-инфраструктуры вызывает полную разруху в проекте целиком. В итоге все потраченные ресурсы деньги, время, люди) оказываются напрасными тратами, отягощенными эмоциональными последствиями "разборок" (и в итоге - неплатежей за уже выполненную работу или "работу").

[Vadim_Zubanov]

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

[Nadir Zaitov]

Ну и как Вы, интегратор, поступите? Я как закачик ;) буду не "слезно просить уложиться в бюджет", а требовать, так как Вы меня "пидманули" - дали неработоспособную небезотказную систему, сволочи акаянные! А ведь знали, что не заработает... а что за "бамажку" Заказчик "просит" - в смысле допу или доплицензии и почему вообще они в конвертике?

[Nadir Zaitov]

Вообще, лучше система с известными недостатками (или даже багами) чем система, недостатки которой исправляли "поверх" ТЗ... так как она вообще непредсказуемой может стать. Не факт... это смотря что написано в ТЗ. Может быть такое (но работоспособное, как ни странно) Заказчику вообще не нужно :).

[Erkin Kuchkarov]

Я как закачик буду не "слезно просить уложиться в бюджет", а требовать, так как Вы меня "пидманули" - дали неработоспособную небезотказную систему, сволочи акаянные! А
Не... со мной такой номер не пройдет - ТЗ то уже утверждено и подписано ;)
а что за "бамажку" Заказчик "просит" - в смысле допу или доплицензии и почему вообще они в конвертике?
Допа - дополнительное соглашение
Лицензии по программе корпоративного лицензирования приходят в запечатанном конверте с указанием номера лицензиара и его реквизитами. Ключей нет :)

[Nadir Zaitov]

Не... со мной такой номер не пройдет. ТЗ то уже утверждено и подписано Просто никто не захотел судиться. Узбекистан на востоке, а восток дело тонкое. Я бы не церемонился и судился бы и выбивал все деньги обратно до последнего пенни обратно, в любом случае проект завалится. Нужно большее, чем утвержденное вами в том числе ТЗ. Тут проблемы не связаны с изготовлением, а с проектированием, а проектировали ВЫ. Пусть проектировалось со мной вместе, но я не специалист и им быть с учетом договора подряда не обязан, иначе зачем мне были б нужны ВЫ :) Суд аргументы скорее примет, а Вас назовет аферистом. Конечно все это только ИМХО, но жить может :).

[Erkin Kuchkarov]

Просто никто не захотел судиться. Узбекистан на востоке, а восток дело тонкое. Я бы не церемонился и судился бы и выбивал все деньги обратно до последнего пенни обратно, в любом случае проект завалится.
Надир - Вы опасный человек, так что меня можете вычеркнуть из списка потенциальных водкопоглатителей.
Не проканает - потому как объектом договора на первом этапе служит утвержденное Вами ТЗ, на втором реализация проекта в строгом соответствии утвержденному ТЗ. Шаг влево шаг вправо - деньги на бочку.
Тут проблемы не связаны с изготовлением, а с проектированием, а проектировали ВЫ. Пусть проектировалось со мной вместе, но я не специалист и им быть с учетом договора подряда не обязан, иначе зачем мне были б нужны ВЫ
Так все и будет гарантированно работать согласно утвержденному и согласованному ТЗ. А Ваши "ночные озарения" можете оставить на следующий проект с моим участием - все сделаем. :)
Суд аргументы скорее примет, а Вас назовет аферистом.
Суд может меня назвать кем угодно в неофициальной, дружеской беседе. Но рассматривать будет только подписанные документы (контрактные обязательства). Так что все Ваши самые сокровенные желания (в рамках проекта) за достойное вознаграждение могут быть выполнены кваллифицированной командой :) Только платите :)

[Igor Ivanoff]

Только платите
Любой каприз, за ваши деньги :)

[Nadir Zaitov]

Только платите
Любой каприз, за ваши деньги :)точнее: Любой большой каприз, за ваши нехилые деньги. Это я тоже знаю :)

[Vsevolod Usmanov]

В отличии от разработчиков - я внедряю "готовые решения". То есть - результат, как цель, должен быть известен до того как будет озвучена цена. В противном случае можно делать один проект всю жизнь - нет предела совершенству. :)
Полностью с Вами согласен. Можно делать один проект всю жизнь и так и не закончить его.:)

Существуют входные качественные и количественные параметры, а именно:
1. Нормативная база...
2. Персонал и материально техническое обеспечение...
3. Кваллификация персонала...
Говоря о разработке заказной информационной системы в этот список необходимо добавить требования, по которым в будущем очень часто возникают споры между заказчиком и исполнителем: Детальные требования к функциям, выполняемым ИС; Требования к модели данных и атрибутам информационных объектов; Требования к стандартам пользовательского интерфейса и т.д.

Если на этом этапе все сделано и удовлетворяет требованиям Заказчика к проектируемой системе (то есть полностью отвечает его ожиданиям и удовлетворяет его потребностям) то о каком изменении может идти чем речь?
Не проканает - потому как объектом договора на первом этапе служит утвержденное Вами ТЗ, на втором реализация проекта в строгом соответствии утвержденному ТЗ. Шаг влево шаг вправо - деньги на бочку.
Если на все время разработки “заморозить” техническим заданием вышеуказанные требования (а они являются неотъемлемой часть ТЗ), то в случае неточного изложения требований или их изменения в процессе разработки, заказчик получит систему, не удовлетворяющую его потребностям. Очень трудно заказчику, не являющемуся специалистом в разработке АС, при разработке ТЗ предусмотреть все точно и сразу, видя прототип системы только на бумаге в виде диаграмм, описаний и т.д. И это не повод разработчикам выкручивать руки заказчику и требовать дополнительных вознаграждений не вовремя процесса разработки, а после сдачи в опытную эксплуатацию.
Процесс реализации проекта по созданию АС не может четко уложится в рассматриваемую жесткую схему на 1, 2, 3 (и только на 3, получив основные деньги, выделенные на проект, мы готовы вернуться на шаг 1 за дополнительное вознаграждение). В процессе будет постоянно возникать необходимость возврата к предыдущим этапам и в уточнении и (или) пересмотре ранее принятых решений, если мы хотим, чтобы проект имел реальный успех.
Поэтому на этапе техно-рабочего проекта (разработки) применяется итеративный метод, когда заказчик может видеть прототип работающей системы, анализировать прототипы автоматизируемых функций на соответствии потребностям его бизнеса и при необходимости вносить изменения и дополнения в техническое задание по договоренности с исполнителем. Естественно, исполнитель в случае трудоемкости предложенных изменений или дополнений вправе потребовать дополнительные суммы.
Другими словами, согласование результатов выполненных работ с заказчиком должно производится не в конкретной точке – сдача в опытную эксплуатацию, а в течении всего техно-рабочего проекта (процесса разработки). Оставляя ему (а также и себе) возможность на исправление допущенных ошибок в описании требований к системе в утвержденном техническом задании. После сдачи в опытную эксплуатацию никакого разговора о внесении каких-либо изменений или дополнений уже быть не может.

[Erkin Kuchkarov]

Vsevolod Usmanov, Я Вас понимаю - но я уже не занимаюсь "заказными разработками". Не барское это дело - скобки расставлять :)

[Eldar Fattakhov]

Очень трудно заказчику, не являющемуся специалистом в разработке АС, при разработке ТЗ предусмотреть все точно и сразу, видя прототип системы только на бумаге в виде диаграмм, описаний и т.д. И это не повод разработчикам выкручивать руки заказчику и требовать дополнительных вознаграждений не вовремя процесса разработки, а после сдачи в опытную эксплуатацию.
Всеволод, здесь не нужно забывать о "специфике" нашего рынка: утверждая ТЗ и формируя бюджет проекта, заказчик срезает суммы предложений с "полным пониманием проекта", а потом начинает умывать руки со словами "невиноватая я"... :) Если бы в учёт принимались обоюдопринятые риски выхождения проекта за рамки утвержденного бюджета, то и вопросов бы зачастую не было.

Еще хуже, когда заказчик "на лету" меняет исходные предпосылки проекта (в первую очередь в части финансирования), которые не ложатся в формулировки договоров пилотной стадии, например. :)

[Nadir Zaitov]

Суд может меня назвать кем угодно в неофициальной, дружеской беседе. Но рассматривать будет только подписанные документы (контрактные обязательства). Договор - не догма. Договор оспорим в каждом его пункте - достаточно несколько пунктов признать ничтожными или не действительными, чтобы сделать из него кавардак. Я не юрист, чтобы спорить, да вижу и Вы не юрист, чтобы оспаривать "прописные истины" судебных разбирательств... ТОлько ради игры рассмотрим такую тактику в судебных разбирательствах: достаточно сказать, что аферистами разворованы бюджетные деньги (вариант - деньги госсобственности) и уже не каждый судья будет мучаться с догадками, кто виноват. Договор можно обжаловать как таковой с эмоциональными криками "Не работает! Меня обманули - мошенничество на лицо. Я ж не могу все знать! Вот у меня дома электричество проводят и я за него плачу - это не значит, что я должен быть инженером-электриком, чтоб его подписывать.", а вместо аргументов привести вашего конкурента (а еще лучше нескольких) в суд и пусть он докажет, что все было в ТЗ сделано "вроде правильно, но суть - вредительство". ;) Экономический ущерб - это уже уважаемая Прокуратура. Вас еще и посадить за такие действия могут, а деньги вернут назвав договор такой вообще недействительным... Как Вам сценарий развития событий?

[Nadir Zaitov]

Eldar Fattakhov, бюджет проекта - дело очень не простое. /Вам легко сказать, чт о нужно столько-то. А как нам оценить это? Как объяснить начальству? Как объяснить, что были многочисленные недоработки в проекте еще до нас и что бюджет уже запущенного проекта нужно увеличить в Эн раз. Политика. Нас просто не поймут.

[Erkin Kuchkarov]

Договор - не догма. Договор оспорим в каждом его пункте - достаточно несколько пунктов признать ничтожными или не действительными, чтобы сделать из него кавардак.
Ок, договорились, Вы объявляете тендер, я его выигрываю и мы судимся. Договорились?

[Eldar Fattakhov]

еще до нас
Это и прочее ранее перечисленное - реальные суперсложности. Как в техническом и технологическом, так и в финансовом плане (не говоря уже о предпосылках морально-этического характера). "Я Вас прекрасно понимаю".

Для нового проекта объяснить не так уж и трудно. Если на том конце "телефонного провода" хотят слышать (даже не слушать). :)

[Erkin Kuchkarov]

Бюджет проекта - дело очень не простое.
УПС.... Так... Бюджет проекта. Есть какая то пирамида потребностей Маслова. У основания размещаем потребности, чуть выше имеющуюся на ИТ ежегодный объем финансирования. Сверху увенчиваем треугольник который описываем как цель, которую мы можем получить исходя из потребностей и коррелируя этапы объемом финансирования.
Самое сложное - утвердить ежегодный бюджет.
В противном случае - проект разрастется до непомерных потребностей, денег и сроков. И все - кирдык всей работе. Но это мое ИМХО и ИМХО руководителей компаний ежегодно планирующих бюджет. Можете с этим ИМХО не соглашаться - делайте через суд.

[Alexander Kuznetsov]

достаточно сказать, что аферистами разворованы бюджетные деньги (вариант - деньги госсобственности) и уже не каждый судья будет мучаться с догадками, кто виноват. Договор можно обжаловать как таковой с эмоциональными криками "Не работает! Меня обманули - мошенничество на лицо. Я ж не могу все знать! Вот у меня дома электричество проводят и я за него плачу - это не значит, что я должен быть инженером-электриком, чтоб его подписывать.", а вместо аргументов привести вашего конкурента (а еще лучше нескольких) в суд и пусть он докажет, что все было в ТЗ сделано "вроде правильно, но суть - вредительство". Экономический ущерб - это уже уважаемая Прокуратура. Вас еще и посадить за такие действия могут, а деньги вернут назвав договор такой вообще недействительным... Как Вам сценарий развития событий?

Посадят сначала того, кто эти деньги отдавал, если они государственные. А если же нет, (да и в любом случае) то будут смотреть бумаги в первую очередь...

А вообще, пустой разговор имхо про это ТЗ. Если ТЗ ненужно или его можно заказчику не придерживаться, то зачем тогда и договора составлять, можно ведь тоже так поставить примерные сроки поставки, примерную спецификацию, применый аванс заплатить... :)

[Ulugbek Umirbekov]

Бюджет проекта - дело очень не простое.
УПС.... Так... Бюджет проекта. Есть какая то пирамида потребностей Маслова. У основания размещаем потребности, чуть выше имеющуюся на ИТ ежегодный объем финансирования. Сверху увенчиваем треугольник который описываем как цель, которую мы можем получить исходя из потребностей и коррелируя этапы объемом финансирования.
Самое сложное - утвердить ежегодный бюджет.
В противном случае - проект разрастется до непомерных потребностей, денег и сроков. И все - кирдык всей работе. Но это мое ИМХО и ИМХО руководителей компаний ежегодно планирующих бюджет. Можете с этим ИМХО не соглашаться - делайте через суд.

Пирмаида Маслоу это в общем-то нечто другое.

[Erkin Kuchkarov]

Пирмаида Маслоу это в общем-то нечто другое.
Чем не ложится в задачу? Давай, давай разъясняй мне, конкурент злостный, скажи мне пару умных слов что бы изменил свое мнение...

[Ulugbek Umirbekov]

Пирмаида Маслоу это в общем-то нечто другое.
Чем не ложится в задачу? Давай, давай разъясняй мне, конкурент злостный, скажи мне пару умных слов что бы изменил свое мнение...

В здешних условиях по этой пирамиде зачастую не выше второго уровня поднимаются. Так что спорить бессмысленно.

А за "злостного" надо будет ответ держать однако :)

[Erkin Kuchkarov]

А за "злостного" надо будет ответ держать однако
И что ты сделаешь? Заныкаешь банку кофе перед моим очередным визитом?
Так я без предупреждений приду :)

В здешних условиях по этой пирамиде зачастую не выше второго уровня поднимаются. Так что спорить бессмысленно.
А... так это я же и сказал. Что это мое ИМХО и ИМХО "иных". У Узбекистана свой путь развития - несколько другой и иногда не отвечающий здравому смыслу. А что делать? У Надира выход один - в суд. Если и суд не решит - тогда прокуратура :)

[Nadir Zaitov]

Пирмаида Маслоу Эта та пирамидка, что из курса Маркетинга?... ЭмБиЭй у кого-то завалялси, а сам под айтишникак косит? Интересно, как Вы на примере какого-нибудь проекта распишите эту пирамиду!

Кстати второй уровень после голода - это безопасность, о которой у нас, ИМХО, думают после реализации всех целей.

[Ulugbek Umirbekov]

Пирмаида Маслоу Эта та пирамидка, что из курса Маркетинга?... ЭмБиЭй у кого-то завалялси, а сам под айтишникак косит? Интересно, как Вы на примере какого-нибудь проекта распишите эту пирамиду!



ЭмБиЭй не завалялси, чесслово. Но что бы ее знать совсем не обязательно что бы он валялся :) Расписывает пусть "злостный" конкурент, он ее в эту тему впихнул :) А под развитие (частью которых являются проекты) лучше бы уже тогда пихнуть колесо Деминга

[Ulugbek Umirbekov]

В здешних условиях по этой пирамиде зачастую не выше второго уровня поднимаются. Так что спорить бессмысленно.
А... так это я же и сказал. Что это мое ИМХО и ИМХО "иных". У Узбекистана свой путь развития - несколько другой и иногда не отвечающий здравому смыслу. А что делать? У Надира выход один - в суд. Если и суд не решит - тогда прокуратура :)

Может лучше uParty? :)

[Erkin Kuchkarov]

А под развитие (частью которых являются проекты) лучше бы уже тогда пихнуть колесо Деминга
Твое колесо Демига того... бесконечное. На примере МинФина - приобретение АС не является основной задачей МинФина (все имена вымышленные, совпадения случайны ). А ты и все пропихиваешь и пропихиваешь. Спекулянт.

[Nadir Zaitov]

Пирмаида Маслоу Эта та пирамидка, что из курса Маркетинга?... ЭмБиЭй у кого-то завалялси, а сам под айтишникак косит? Интересно, как Вы на примере какого-нибудь проекта распишите эту пирамиду!



ЭмБиЭй не завалялси, чесслово. Но что бы ее знать совсем не обязательно что бы он валялся :) Расписывает пусть "злостный" конкурент, он ее в эту тему впихнул :) А под развитие (частью которых являются проекты) лучше бы уже тогда пихнуть колесо Деминга
О-ооооопс... А я думал, что писал "счастливому обладателю бибики" :) Ошибси... Конечно же вопрос к нему! Пусть про Маслова нам тут расказывает, а мы 31-го на uPraty это тоже отметим ;)

[Ulugbek Umirbekov]

А под развитие (частью которых являются проекты) лучше бы уже тогда пихнуть колесо Деминга
Твое колесо Демига того... бесконечное. На примере МинФина - приобретение АС не является основной задачей МинФина (все имена вымышленные, совпадения случайны ). А ты и все пропихиваешь и пропихиваешь. Спекулянт.

Дык и развитие (если оно есть) должно быть бесконечным с определенными checkpoint'ами. Кстати, CheckPoint.... :)

[Nadir Zaitov]

P-D-C-A всегда был похож на "динамо". И тут Улугбек прав - он должен продавать что-либо регулярно и периодически, а не делать вечные решения ;)

[Nadir Zaitov]

У Надира выход один - в суд. Если и суд не решит - тогда прокуратура У меня один выход - сделать все правильно, а если это не решит, то в морг. Ответственный я :)

[Ulugbek Umirbekov]

P-D-C-A всегда был похож на "динамо". И тут Улугбек прав - он должен продавать что-либо регулярно и периодически, а не делать вечные решения ;)


А попробуйте примерить этот принцип к своей работе. И организации хорошо ну и остальным неплохо :)

[Nadir Zaitov]

А попробуйте примерить этот принцип к своей работе. И организации хорошо ну и остальным неплохо Ой, блин. Я вот с ISO 9000:2000 сталкивался еще лет 5 назад - не по наслышке знаю. Применяю, где могу и возможно. Но проект по этому принципу развивать не буду, за что прошу Вас меня извинить (расстреляют на первом зацикливании) ;).

[Erkin Kuchkarov]

Дык и развитие (если оно есть) должно быть бесконечным с определенными checkpoint'ами. Кстати, CheckPoint....
Думаешь присосаться? Если хороший объем, то я подумаю о чекпойнте... семизарядном. Вывезу куда нить... скажем уточек пострелять.. и все.
Утка не утка но гуся свалим.. или кабаняку.. смотря что ты прокричишь :)
Шутка... пока... пока шутка :)
Ок... все понятно развитие... а ключевое что тут? Потребности? Бюджет? Где конец процесса то? Или проект будет называтся "Путь Ильича"?
Проходили же...

[Nadir Zaitov]

Ок... все понятно развитие... а ключевое что тут? Потребности? Бюджет? Где конец процесса то? Или проект будет называтся "Путь Ильича"? Вопрос ко мне?

[Erkin Kuchkarov]

Вопрос ко мне?
Да Вы уже показали свою профнепригодность заявив что вы представляете "Заказчика"... Не к Улугбек. Тот видать пошел писать оперу что я ему угрожаю

[shumbola]

не возможно читать тему, все в офтопах. :-)
специально мой офтоп вам без тега офтоп. :biggrin:

[Ulugbek Umirbekov]

Дык и развитие (если оно есть) должно быть бесконечным с определенными checkpoint'ами. Кстати, CheckPoint....
Думаешь присосаться? Если хороший объем, то я подумаю о чекпойнте... семизарядном. Вывезу куда нить... скажем уточек пострелять.. и все.
Утка не утка но гуся свалим.. или кабаняку.. смотря что ты прокричишь :)
Шутка... пока... пока шутка :)
Ок... все понятно развитие... а ключевое что тут? Потребности? Бюджет? Где конец процесса то? Или проект будет называтся "Путь Ильича"?
Проходили же...

Ключевое тут стратегия развития ИТ в организации, а проекты это те самые чекпоинты и есть

[Erkin Kuchkarov]

Ключевое тут стратегия развития ИТ в организации
Хорошо, раз мы разводим тут демагогию, а не тепленького клиента, расскажи мне чего стоит стратегия если нет денег? ;)

[Ulugbek Umirbekov]

Ключевое тут стратегия развития ИТ в организации
Хорошо, раз мы разводим тут демагогию, а не тепленького клиента, расскажи мне чего стоит стратегия если нет денег? ;)

Ровно столько же сколько и проект без денег :)

[Erkin Kuchkarov]

Ровно столько же сколько и проект без денег
А что клиенту надо - стратегия или проект?

[Gebo]

А что клиенту надо - стратегия или проект?
"Что б все работало."

[Alexander Kuznetsov]

Ключевое тут стратегия развития ИТ в организации, а проекты это те самые чекпоинты и есть

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

[Erkin Kuchkarov]

"Что б все работало."
Ясно же сказано - нет финансирования. То есть оно есть... скажем на один компьютер, а потом, в процессе эволюционирования согласованного и утвержденного ТЗ(по которому делается проект) будут выдвинуты требования которые в рамках бюджета на один компьютер должны позволить Заказчику отстроить и внедрить точно в срок современную, высокопроизводительную, отказоустойчивую, защищенную информационную систему со всеми подсистемами. При чем "пирамида потребностей Маслоу" тут не подходит - нужен цикл развития, желательно бесконечный. Иначе СУД!

[Ulugbek Umirbekov]

Ровно столько же сколько и проект без денег
А что клиенту надо - стратегия или проект?

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

[Erkin Kuchkarov]

Клиенту нужны деньги для того что бы посредством выполнения проектов стремиться к выполнения стратегической задачи.
А... ну дык эту "стратегическую задачу" можно описать одним предложением в терминах "миссия" или "девиз". И стоит на это тратить время таких инженеров с инженерным подходом как я? Занимайся.

[Nadir Zaitov]

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

[Erkin Kuchkarov]

Если нет денег, то не стоит. А если деньги вдруг есть?
Так есть деньги или нет?
(Улугбек - ну ка кыш отсюда... видишь как все обернулось то.. ;) )
Нет... вопрос поставим по другому:
"Я так понимаю, что деньги есть, но нет описанной задачи и как следствие неизвестны требуемые реальные объемы финансирования" ?
собранное из непрофессиолов в IT
Является ли ИТ основной задачей ГРП? Нет?

Тогда Вам ко мне с инженерным подходом, нежели нахватавшемуся всяких купеческих премудростей Улугбеку. Потому, что он какой то "gold certified partner", а я "GOLD CERTIFIED PARTNER" :)

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

[Nadir Zaitov]

Ну пошутили и будет, в самом деле раз Вы решились на какую то автоматизацию подконтрольной или вышестоящей или смежной организации и выносите "болячки" тут то советую Вам для начала хотя бы описать (своими словами... не надо гостов или рд) чего Вы ожидаете. Вот учишься, учишься, а потом раз... (с) пришел ЭК и все как Ржевский опошлил поставил не на свои места... Если б я мог вам рассказать все, то лишил бы вас возможности учавствовать в тендерах как консультанта, учавствовавшего в подготовке тендера, что не приемлемо. Раз у вас есть много различных возможностей, то начну с самого простого: сколько различных решений для Казначейства государства вы знаете. Уточню: обычные требования к программному комплексу казначейства - это:

The World Bank Treasury Reference Model (TRM);
The IMF Code of Good Practices on Fiscal Transparency;
United Nations Common Functions of Government (COFOG);
International Federation of Accountants International Public Sector Accounting Standards Board International Public Sector Accounting Standards (IPSASs).Что то подобное в документах и описано... Писали иностранные консультанты много и много лет назад: разные люди, в разное время и фактически о разном... В результате нашли деньги (лимиты денег считали вообще третии люди) на такое вот гетерогенное создание, которое потом назвали нашим проектом. Как спеца по "готовым решениям" для начала, прошу представить список близкий по содержанию решений (в основном пункт первый - остальные забудьте пока).

[Erkin Kuchkarov]

(в основном пункт первый - остальные забудьте пока).
Вы меня заинтриговали... то есть в случае реализации данного проекта к перманентному, национальному финансовому кризису добавят еще и мировой? А где мы будем жить?

[Nadir Zaitov]

А где мы будем жить? Вы меня тоже заинтреговали! В Ташкенте, в благополучно, солнечном, и уже фискально прозрачном Узбекистане :)

[Nadir Zaitov]

Кстати, мы находимся сейчас на первой стадии проекта по Эльдаровской классификации (http://uforum.uz/showthread.php?p=175897#post175897).

[Erkin Kuchkarov]

Кстати
Что то совсем не кстати. Улугбек!!! Забирай Надира!!!

[Nadir Zaitov]

Что то совсем не кстати. Улугбек!!! Забирай Надира!!! Проталкиваете проект на вторую стадию :)ЧТо нибудь интересное нашли?

[Erkin Kuchkarov]

ЧТо нибудь интересное нашли?
Пока тупо читаю... изучать будем вместе. Но уже есть вопросы... и первый из них "а зачем?" (считайте что Ваш ответ можно будет вставить в преамбулу)

[Nadir Zaitov]

"а зачем?" Выдам отдельными эмоциями (словами не получится - не я автор):

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

2) единый счет (нет остатков на куче бюджетных счетов - естьодин огромный остаток на едином казначейском счету...

3) сквозной учет обязательств - все договора, будущие платежи на контроле...

4) Повышение качества бюджетирования (прогнозирования, исправления)...

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

В общем Казначейство в том понимании - это антикоррупционная система.

[shumbola]

В общем Казначейство в том понимании - это антикоррупционная система.
Сильно сказано. :-)

[Erkin Kuchkarov]

Выдам отдельными эмоциями
Нехило... и некисло будет интегратору.

Вопрос: Хоть что нибудь (относительно объектно-ориентированной модели структуры отраслевой информации "незнаюещекакобозвать" ) из того что Вы мне дали внедрено в целевой организации?

[Erkin Kuchkarov]

Сильно сказано. :-)
Не то слово - "АРМ антикоррупционера" vs "АРМ коррупционера"... война миров :)

[Nadir Zaitov]

Сильно сказано. :-)
Не то слово - "АРМ антикоррупционера" vs "АРМ коррупционера"... война миров :)
Что по мне, то это как инь-янь - об одной и той же информационной системе говорите :)

[Nadir Zaitov]

Вопрос: Хоть что нибудь (относительно объектно-ориентированной модели структуры отраслевой информации "незнаюещекакобозвать" ) из того что Вы мне дали внедрено в целевой организации? Второй и третий в значительной части, первый частично.

[Erkin Kuchkarov]

Второй и третий в значительной части, первый частично.
О как!... выходит, что все частично. Мда... тяжко совсем.

[Nadir Zaitov]

Сообщение от Nadir Zaitov Второй и третий в значительной части, первый частично.
О как!... выходит, что все частично. Мда... тяжко совсем. Согласен... А еще плохо описано, что вообще труба :( Разбираюсь пока и сам.

[Vsevolod Usmanov]

... начну с самого простого: сколько различных решений для Казначейства государства вы знаете...
Из известных решений на рынке присутствуют три: немецкая SAP, американские Oracle EBS и PeopleSoft.
В России и Казахстане внедряли Oracle EBS.

[Erkin Kuchkarov]

Из известных решений на рынке присутствуют три: немецкая SAP, американские Oracle EBS и PeopleSoft.
В России и Казахстане внедряли Oracle EBS.
MS Dynamics Ax в той же России или в Казахстане. И тут речь вообще то не идет о конкретном продукте :)

[Vsevolod Usmanov]

MS Dynamics Ax в той же России или в Казахстане. И тут речь вообще то не идет о конкретном продукте :)
Слово не даете сказать :) Всё Microsoft, Microsoft ... Как нету Microsoft, так и сразу - "речь вообще то не идет о конкретном продукте" :)
Интересно, а есть ли примеры внедрений MS Dynamics Ax (бывшая Axapta, если не ошибаюсь) в качестве "решения для Казначейства государства"? :)

[Erkin Kuchkarov]

Интересно, а есть ли примеры внедрений MS Dynamics Ax (бывшая Axapta, если не ошибаюсь) в качестве "решения для Казначейства государства"?
Есть - зайдите на сайт майрософт и поищите по продукту внедрения :)

Слово не даете сказать
Да пожалуйста, говорите. Я же не говорю о майкрософт в этой ветке. даже не намекал потому как возможно это будет SAP, возможно Oracle EBS, возможно Ax, Nav.... да хоть 1С - главное что бы отвечала требованиям Заказчика.
Речи вообще идти не может о чем либо.

[Nadir Zaitov]

В России и Казахстане внедряли Oracle EBS. Внедряли и внедрили - разные вещи! В России слышал не внедрили...

[Nadir Zaitov]

Есть - зайдите на сайт майрософт и поищите по продукту внедрения Нет бы ссылочку кулюторно тут оставить... вот теперь всем идти и искать :(

[Vsevolod Usmanov]

В России и Казахстане внедряли Oracle EBS. Внедряли и внедрили - разные вещи! В России слышал не внедрили...Государственные проекты не получают негативных оценок и проекты в госорганизациях никогда не заканчиваются неудачно. Поэтому я осторожно сказал - внедряли :)
Хотя можно отметить, что работы по модернизации казначейства России по сей день продолжаются, а казначейство Казахстана стало "первым в мире" (http://www.inform.kz/showarticle3.php?lang=rus&id=213827) и продолжает (http://www.izvestia.kz/news.php?date=29-01-09&number=3) начатое… :)

[Eldar Fattakhov]

стало "первым в мире" и продолжает начатое…Первым в мире, судя по "наводке", оно стало внедрять новую версию Applications (R12). :)

А так оно нормально работает и реально развивается (на платформе HP).

[Nadir Zaitov]

Первым в мире, судя по "наводке", оно стало внедрять новую версию Applications (R12). Там странно прозвучал "электронный документооборот в двух офисах казначейства" .... т.е. Казначейство у них не централизовано?

[Nadir Zaitov]

А еще убило выражение:

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

[Eldar Fattakhov]

Там странно прозвучал "электронный документооборот в двух офисах казначейства" .... т.е. Казначейство у них не централизовано?Почему не централизовано?! Централизовано (в ядре системы несколько серверов HP SuperDome и дисковых массивов XP). Речь идет о "пилотировании" системы документооборота на основе двух крупнейших филиалов (Алматы и Астана). У нас тоже всё начиналось в двух областях... :)

Остальные "убийства" (безопасность, пакетный режим) - проблемы перевода с русского на русский (от менеджера к журналисту). :)

[Nadir Zaitov]

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

[Nadir Zaitov]

HP SuperDome и дисковых массивов XP А конфигурацию всей системы услышать/увидеть можно? Все ж есть вопросы:

1) HP SuperDome супердому рознь: нужно б узнать сколько там процессоров, какая память, сколько дисков в массиве. Массив, я так понимаю, XP24000? Идея в том, чтоб было не меньше 1000 дисков для производительности ;)? Почему не подошли EVO 8100, например?

2) Видел нагрузку в 15000 бюджетополучателей. Какие функции казначейства задействованы (какие модули работают)? Задействован аccruals или cash accounting? Есть accruals, то ведется ли бухучет бюджетополучателей также на этих супердомах или всеж речь идет о Казначействе, как о системе управления единым счетом?

3) Сколько стоил комплекс в Центральном Казначействе, если была разбивка? Если есть отдельно железо, отдельно софт, то буду признателен.

Для справки, в Узбекистане где-то 40 000 бюджетополучателей, уже сейчас задействованы 23 000, так как некоторые школы и детсады не имеют статуса юридического лица. Как вы думаете, как это отразится на числе процессоров и оперативной памяти?

[Erkin Kuchkarov]

в Узбекистане
Главное в Узбекистане, что бы никто SuperDom не путал с "супер домом" :)

[Eldar Fattakhov]

Почему не подошли EVO 8100, например?
По дисковым массивам можно отследить историю. Вначале были дисковые массивы VA (Virtual Array, уже сняты с производства - так давно это было), потом пришла EVA (ненадолго), следом - XP.

Дисковые массивы XP - это high-end дисковые массивы, отличающиеся много чем (размер кэш-памяти, количество дисков, немаловажно - есть уже отсутствующие в EVA диски 73 ГБ, ...). Но одно из главных преимуществ XP - возможность разделения ресурсов (partitioning), когда разным департаментам можно выделять собственные ресурсы на уровне контроллеры (гарантированная пропускная способность).

Короче говоря, XP намного круче ЕВы! :) Конечно же, в соответствующем классе решений.

[Eldar Fattakhov]

Сколько стоил комплекс в Центральном Казначействе
Боюсь, что эта информация не будет доступна. :)

[Nadir Zaitov]

Боюсь, что эта информация не будет доступна. Жаль. понимаю, что это их право.
Короче говоря, XP намного круче ЕВы! И с этим соглашусь, хотя кажется партишенинг был и в EVO, возможно без разделения...

Остались самые интересные для меня вопросы :): сколько процессоров и памяти на узле, сколько узлов и сколько дисков в дисковом массиве. Надеюсь это не секрет?

Ах, да еще остались вопросы по функционалу казначейства Казахстана. Вот.

[Ахадбек Далимов]

Ах, да еще остались вопросы по функционалу казначейства Казахстана.
Наверное вам легче будет достучаться до коллег в казахстане ...

[Erkin Kuchkarov]

И с этим соглашусь, хотя кажется партишенинг был и в EVO
EVO использует EVA, это так... для справки ;)

[Nadir Zaitov]

Наверное вам легче будет достучаться до коллег в казахстане ... Коллеги ведь не смогут объяснить детали решения. А вот это (http://www.minfin.kz/index.php?uin=1168403492&lang=rus) ...
В октябре 2005 года представительством компании Hewlett –Packard в СНГ Комитету казначейства от имени Всемирного компьютерного фонда были вручены медаль и сертификат международной программы The ComputersworldHonors «Поиск новых героев» в категории «Государственные и некоммерческие организации» за внедрение Интегрированной информационной системы казначейства.
.. достойно того, чтобы показывать это модельное решение всем подряд именно компании Hewlett –Packard, что конечно же там же и указано:Сегодня многими экспертами признается, что в Казахстане сформирована лучшая в Содружестве Независимых Государств современная интегрированная информационная система казначейства. Проект модернизации казначейства получил высокую оценку экспертов МВФ, МБРР и руководителей проектов из стран СНГ, Китая, Словакии, Палестины, Монголии, США, Болгарии. Модернизация системы казначейства признана уникальной моделью и рекомендована как потенциальная модель для возможности распространения опыта Казахстана среди других стран.

[Eldar Fattakhov]

еще остались вопросы
Надир, я постараюсь "раздобыть" сведения. Смогу поделиться, наверное, но не для широкой общественности. Я извещу дополнительно.

[Nadir Zaitov]

EVO использует EVA, это так... для справки Блин, очипятки - мой бич! Конечно же я знаю...

[Ахадбек Далимов]

Коллеги ведь не смогут объяснить детали решения.
Думаете?
...

[Nadir Zaitov]

Надир, я постараюсь "раздобыть" сведения. Жаль, что нельзя обсудить тут, был бы очень признателен если дадите знать когда и как забрать информацию.
Думаете? Я благодарен Эльдару Фаттахову, что не придется "упрашивать" коллег (финансистов, я полагаю) объяснить IT-решение и функционал. :)А точнее искать в Казначействе ответственного за все это дело, или ответственных за каждую часть.

[Yuliya Yamaltynova]

Понравилась статья (http://www.klubok.net/article2303.html), касающаяся ИС. Может тем, кто занимается разработкой и внедрением ИС будет полезна.

[Alexander Kuznetsov]

Nadir Zaitov, извиняюсь, может быть, я не прав, (т.к. не в курсе до конца о ситуации с Вашим проектом), но, если у Вас есть конкретная задача (а может и сроки), то не лучше ли организовать встречу со специалистами, которые помогли бы разобраться и подобрать правильное решение именно под Ваш проект? Организовать круглый стол или рабочую комиссию пригласить вендоров, возможных интеграторов...? По-моему, Вы пытаетесь все взвалить на себя, - это не продуктивно. Да и на форумах или в "гуглах" собирать по крупицам информацию тоже. К примеру, если мне нужен телефонный номер НР, то я могу поискать это в интернете, могу позвонить в справочную, но проще всего мне просто спросить у Эркина (не сочтите это за грубую рекламу :) )
Сейчас, почему-то модно ориентироваться на Казахстан при разработке гос. ИС. Не хочу сказать, что Казахстан - плохой пример, но внедрить одинаковую систему в двух одноплановых организациях, которые находятся в соседних зданиях и вроде бы выполняют схожие функции - крайне сложно, что уж говорить об организациях из разных государств...

[Nadir Zaitov]

не лучше ли организовать встречу со специалистами, которые помогли бы разобраться и подобрать правильное решение именно под Ваш проект? Организовать круглый стол или рабочую комиссию пригласить вендоров, возможных интеграторов...? По-моему, Вы пытаетесь все взвалить на себя, - это не продуктивно Согласен, только вендоры учавствовавшие в разработке проекта по правилам АБР исключаются из списка имеющих право учавствовать в тендере. Возможные интеграторы также должны отозваться на призыв к тендеру, а не участвовать в его разработке. Чувствуете разницу? А задача есть, но она не конкретная страшно.К примеру, если мне нужен телефонный номер НР, то я могу поискать это в интернете, могу позвонить в справочную, но проще всего мне просто спросить у Эркина А мне позвонить в HP Эльдару Фаттахову и спросить у него.
Кстати недавно пришлось звонить в офис HP в Москве и на Украине, так они не знали телефонов офиса в Ташкенте, точнее их телефоны уже были устаревшими, а на нашем форуме оказались актуальные.

[Alexander Kuznetsov]

Согласен, только вендоры учавствовавшие в разработке проекта по правилам АБР исключаются из списка имеющих право учавствовать в тендере. Возможные интеграторы также должны отозваться на призыв к тендеру, а не участвовать в его разработке. Чувствуете разницу? А задача есть, но она не конкретная страшно

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

[Nadir Zaitov]

Может быть, тогда провести конкурс или тендер (или просто выбрать) на системного интегратора, в функцию которого будет входить разработка проекта, проведение экспертизы и авторский надзор? А потом уже объявлять тендера на поставку железа, софта, услуг и пр. согласно проекту. Или провести тендер на "генподрядчика без права поставки", который будет писать проект и выполнять по нему работы, но для поставки должен будет нанимать субподрядчиков (на конкурсном или тендерном отборе). ТЭР утвердили до меня. Что-то подобное в свое время я и предлагал: "полную проектировку" до ТЭР, а потом идти на "шопинг" оборудования и софта, но уже поздно - поезд ушел. Как всегда пытаемся теперь найти разумный выход из дурацкой ситуации и при этом при ограниченном наборе оборудования.

[Erkin Kuchkarov]

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

[Alexander Kuznetsov]

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

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

[Nadir Zaitov]

Самый разумный - отказаться. Пройденный этап. Я уже отказывался ДО перехода в ГРП.
а потом расширять и совершенствовать и планировать под это новый бюджет. Улыбнуло. Идея "пилотного проекта" не нова и у нас не раз применялась. Однако к нам это не подходит.

[Alexander Kuznetsov]

Улыбнуло. Идея "пилотного проекта" не нова и у нас не раз применялась. Однако к нам это не подходит.

Я так и думал, что зря вставил в свой пост "пилотный проект". :) Я имел в виду, что если есть бюджет и задачи, то можно определить в каком объеме можно эти задачи в этом бюджете реализовать. т.к. бюджета не хватает (как я понял), то можно:
1. Реализовать те задачи, на которые хватит бюджета. Развивать эту мысль дальше буду, т.к. скорее всего это для Вас неприемлемо.
2. Реализовать всю номенклатуру задач, но в том объеме - на который хватит бюджета. Отчитаться. Пусть все работает, но с нагрузкой не справляется. Почему? Потому что за это время вырос объем работы, устарело оборудование, поменялись задачи и прочее (скорее всего так и есть). Это все можно задокументировать на испытаниях при вводе в эксплуатацию и там же предложить решения. Это все законно и соответствует нормам.
А проект вообще проходил экспертизу? Может быть отдать его на экспертизу и пусть она скажет, что проект нужно доработать.

[shumbola]

Пусть все работает, но с нагрузкой не справляется.
Это как понять? Типа оборудование слабое? Бывает, что основную часть расходов отводять на оборудование, думают софт стоит мелочи, в крайнем случае можно украсть. ;-)
Если что-то другое имели ввиду, объясните.

[Alexander Kuznetsov]

Бывает, что основную часть расходов отводять на оборудование, думают софт стоит мелочи, в крайнем случае можно украсть. ;-)

Так и оборудование можно украсть :)

[Nadir Zaitov]

Бывает, что основную часть расходов отводять на оборудование У нас так и сделали. Может действительно думали остальное украсть? :) :) :)

[shumbola]

Бывает, что основную часть расходов отводять на оборудование, думают софт стоит мелочи, в крайнем случае можно украсть. ;-)

Так и оборудование можно украсть :)

Оборудование не так легко украсть, и за кражу оборудования в тьюрму могут посадить.

[shumbola]

Бывает, что основную часть расходов отводять на оборудование У нас так и сделали. Может действительно думали остальное украсть? :) :) :)

Незнаю что в действительности думали. Но таких примеров куча.

Если так, советую смотреть в сторону опен соурс. ;-)

[Nadir Zaitov]

Если так, советую смотреть в сторону опен соурс. ;-) А много опенсоурс решений на производительных системах класса mid-range или hi-end для финансового сектора ???? Я не слышал ни об одном, хотя возможно заблуждаюсь и такие есть. :)

[Alexander Kuznetsov]

Оборудование не так легко украсть, и за кражу оборудования в тьюрму могут посадить.

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

[shumbola]

Оборудование не так легко украсть, и за кражу оборудования в тьюрму могут посадить.

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

ПризПримеры в студию! Только, далеко ходить не надо.

Вполне можно представить такой проект на левом софте. А что экстраординарного? Отвечать будут те, кто такой проект сделают.

Я не буду с вами спорить об опен соурс.

[shumbola]

Если так, советую смотреть в сторону опен соурс. ;-) А много опенсоурс решений на производительных системах класса mid-range или hi-end для финансового сектора ???? Я не слышал ни об одном, хотя возможно заблуждаюсь и такие есть. :)

Честно говоря я незнаю что есть для финансового сектора применительно к вашей задаче. Но думаю, что можно соорудить с малыми силами (имеется ввиду деньги).

[Erkin Kuchkarov]

А у опенсурс кстати бесплатен только до определенной границы. И такой проект дежит далеко за ней.
Саша, предлагаю не спорить с шумбалой. Он на опенсурце (и не только) бабки зарабатывает. Реальные.

[shumbola]

А у опенсурс кстати бесплатен только до определенной границы. И такой проект дежит далеко за ней.
Саша, предлагаю не спорить с шумбалой. Он на опенсурце (и не только) бабки зарабатывает. Реальные.

Ha-ha-ha. Вы же меня не знаете, откуда дровишки? ;-)

[Erkin Kuchkarov]

Ha-ha-ha. Вы же меня не знаете, откуда дровишки? ;-)
??? JVM уже продаете?? Я сужу из того что прочитал. А Саша у нас - начальник отдела продающего ПО. Попросту - мерчендайзер одной, почти канадской, конторы :)