Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

25.03.2017

Google
WWW CITForum.ru
С Новым годом!
2000 г

Об оценке эффективности внедрения и применения систем управления ресурсами предприятия.

С. Колесников, [it_info@iname.com]
кандидат физико-математических наук
ведущий рубрики Consulting.ru
Директор по консалтингу КГ (Консалтинговая Группа) "Экон-профи"

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

Особую пикантность ситуации придает тот факт, что в западной практике этот же вопрос, активно обсуждавшийся 4-5 лет назад, в настоящее время практически "закрыт", будучи сведен к простой формуле, связывающей обороты компании и уровень затрат на создание системы управления ресурсами: (стоимость СУР)=(0.01-0.03)х(годовой оборот компании). К ней мы вернемся в конце статьи.

Из чего складывается стоимость типичного проекта внедрения?

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

Если ПО СУР состоит из нескольких компонент, то принципы лицензирования разных компонент могут отличаться, что-то может лицензироваться также на рабочие места, что-то на сервер, а что-то вообще на компанию-клиента. В любом случае нужно точно выяснить у поставщика, какие компоненты входят в заявленную им стоимость ПО и каковы правила расширения поставки, например приобретения дополнительных рабочих мест или лицензий по каждой из компонент.

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

Заключает первую триаду стоимость поддержки и сопровождения ПО СУР и СУБД. Она обычно составляет 15-20% от их суммарной полной стоимости по контракту, за годичный период сопровождения, и включает в себя такие компоненты как "горячая линия" - поддержка по телефону, бесплатная поставка новых релизов и версий программного обеспечения, ответы на письменные запросы клиента, бесплатное устранение обнаруженных ошибок, и, возможно, ряд других условий. В договоре должны быть четко определены термины и порядок оказания всех перечисленных услуг, иначе потом вряд ли удастся доказать, что вы об этом договаривались. Особенностью российской специфики является частые изменения бухгалтерского и налогового законодательства, которые для своей реализации могут потребовать существенного вмешательства не просто в отчестве формы, но и в бизнес-логику продукта. Такого рода изменения могут не попадать под условия стандартного договора о сопровождении даже отечественных производителей.

И, наконец, последняя и нередко самая весомая компонента - стоимость внедрения. Наиболее просто вычисляемым и удобным для покупателя является вариант "внедрения под ключ", но чаще встречается вариант оплаты по часам и по работам, перечень которых определяется по мере необходимости или предварительно, исходя из некоторого типового плана внедрения. Из практики работы на российском рынке можно оценить стоимость внедрения любого ПО СУР не менее чем стоимость всех перечисленных выше компонент ПО (стоимость которого принята за 1), то есть 1:1. Окончательная стоимость обычно бывает больше и достигает уровня 1:3-5. Если вам обещают внедрение менее чем за половину стоимости ПО, то лично у меня это вызвало бы подозрения - либо стоимость ПО сильно завышена, либо ваши собеседники что-то не договаривают о внедрении. Ряд поставщиков под единым термином "поддержка внедрения", включаемым в стоимость контракта, понимают формально рассчитанную стоимость работы своих консультантов исходя из их минимальных трудозатрат на год внедрения. Услуги по внедрению в этом случае будут также предоставляться на почасовой основе.

При более детальном исследовании оказывается, что стоимость внедрения тоже представляет собой триаду: обучение проектной группы, инсталляция ПО, интеграция компонент системы и доведение продуктов до действующей модели. В более сложном случае последний этап, который было бы правильно назвать собственно внедрение, как это ни странно, также представляет собой триаду: подготовка исходных данных, построение модели предприятия с помощью ПО СУР, устранение возникших расхождений модели и реального предприятия. И наконец, обычно для полного внедрения данный процесс часто приходится повторить именно три раза. Из перечисленных выше элементов внедрения процесс инсталляции и интеграции компонент обычно, к счастью, в российской практике включается в стоимость ПО или делается бесплатно, хотя это и не обязательно всегда так.

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

Таким образом теперь мы знаем как определить стоимость покупки. Как же определить эффективность внедрения системы?

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

Первый пример - внедрение штрих кодирования. Обычно при этом говориться о повышении скорости отпуска товаров и обслуживании покупателей, при этом оценка эффективности - 20-50 % ускорения - типовая цифра связанная с чистым ускорением считывания данных о товаре, ориентированная на то, что и без штрих кодов общий процесс продаж был хорошо отлажен. Если же процесс налажен не был, то естественное его упорядочение может дать еще более существенный эффект.

Но вот компания "Розовый гусь" приобрела оборудование стоимостью 15000$, а эффекта от увеличения скорости отпуска вроде бы не получила. В чем причина? Все очень просто - скорость отпуска и не была критичным параметром ( отпуск элитной сантехники, в данном случае), и естественно никакого ускорения получено и не могло быть, так как основное время уходило на поиск товара и его перетаривание при погрузке. Означает ли это, что внедрение штрих кодирования было неэффективно? Конечно нет! Просто неверно был выбран критерий оценки эффективности. В данном случае необходимо было оценивать результат от снижения ошибок при отпуске товара, особенно оптовом. Средняя квартальная стоимость ошибок оценивалась в 2500$, то есть 10000$ в год. После внедрения штрих - кодирования эта цифра упала до 1000 - 2000$ в год. Легко видеть, что понесенные затраты на внедрение могут окупиться в течение менее чем двух лет, не считая положительных результатов от других аспектов внедрения, таких как например расширение ассортимента товаров и сопутствующее этому увеличение оборота и доходов.

Второй пример - часто дискутируемый вопрос о сокращениях в штате бухгалтерии при внедрении систем. Если эти сокращения произошли, то эффективность рассчитывается просто (годовой бюджет заработной платы)х(срок амортизации продукта - 3-5 лет минимум). Но вот компании "Черный металл" и "Пищевой продукт" вместо сокращения бухгалтерии получили увеличение штата на 5 и 10 человек соответственно.

Означает ли это, что они вместо повышения эффективности получили дополнительные затраты?

Оказывается, необязательно (оба пример основаны на реальных фактах, хотя названия и некоторые параметры компаний изменены).

Компания "Черный металл" увеличила штат за счет аналитического отдела бухгалтерии. Основными задачами аналитического отдела является анализ затрат и разработка путей их минимизации за счет появившейся возможности детального анализа издержек. Даже весьма пессимистичный прогноз, точнее оценка, полученная в конце первого года работы, - 1-2% снижения затрат на производство, учитываю размер оборотов компании , оправдывает как увеличение штата, так и само приобретение системы.

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

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

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

Например до внедрения системы, время, затрачиваемое на отпуск, продукции, составляло 30 минут. Для обслуживания максимального количества покупателей необходимо было 20 менеджеров. При этом увеличивать штат было практически невозможно а следовательно, невозможно увеличить клиентуру. После внедрения на обслуживание одного покупателя стало уходить не более 10 минут. Таким образом для обслуживания обычного количества покупателей было бы достаточно 20/(30/10)~7 менеджеров. Взяв запас на критические дни, пиковые нагрузки во время предпраздничных распродаж и возможное увеличение клиентуры, можно оставить 10 человек. В этом случае эффект от внедрения системы управления продажами составит (годовой уровень зарплаты 10 менеджеров)х(срок амортизации системы). Естественно, дополнительный эффект может быть получен за счет увеличения клиентуры.

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

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

Такой проект весьма длителен и дорогостоящ, а главное, крайне субъективен. По параметрам длительности и стоимости он сравним, если не превышает, сам проект внедрения. Типичными параметрами длительности такого проекта являются 6-9-12 месяцев по данным западной прессы, а в Российской практике еще больше, к тому же оценка результатов внедрения вещь весьма зыбкая. Опять же требуются очень высококвалифицированные специалисты по ИС и управлению бизнес-процессами для оценки возможных последствий внедрения, так что провести подобный проект "своими силами" практически невозможно. Как к тому же хорошо известно, далеко не всегда проект внедрения приводит к положительному результату, и уж точно трудно однозначно предсказать и оценить результаты внедрения до его полного завершения.

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

Тем не менее вопрос об эффективности внедрения остаётся на повестке дня, так как любые крупные затраты требуют обоснования.

Что делать ? Оценка результативности внедрения проводится по "средним отраслевым результатам", именно такие результаты обычно приводятся в маркетинговых материалах и в открытых публикациях.

Типичными "средними" результатами внедрения можно считать такие достижения:

n 15-25% увеличение производительности

n 10-20 % уменьшение складских запасов

n 20-50% сокращение сроков выполнения заказов

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

Типичным примером можно считать скажем такую задачу: крупная компания, например "А-кола", имеет в стране сеть филиалов и представительств, которой занимается оптовой продажей продукции, решает построить завод в России. При этом в филиалах используется программный продукт типично торгового назначения, поддерживающий функциональность финансы - простой склад - продажи. Больше собственно, ничего и не нужно, так как номенклатура продукции - всего 9-15 наименований.. Но заводу требуется программный продукт для расчета потребности в материалах и компонентах, то есть MRP - продукт. Имеет ли смысл приобретать, скажем BAAN или SAP R/3 и на их основе полностью заменять программное обеспечение во всех офисах? Маловероятно. Гораздо удобнее поставить специализированный, обычно существенно более простой и дешевый софт исключительно для расчета потребности в материалах. Оценить последствия такого внедрения гораздо легче, да и проект внедрения существенно более управляем и реалистичен.

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

"Локальность внедрения" очень распространенная ситуация на Западе. Его материальным выражением является наличие одних и тех же компаний, как правило очень крупных, с большим числом филиалов и подразделений, в референс-листах многих производителей программных продуктов. Очень популярными участниками таких списков является, например, Siemens AG, АВВ, Кока-Кола и многие другие "multi-national". К этому надо добавить, что во многих таких компаниях "фирменная" политика фиксируется на уровне корпоративных стандартов учета и управления, а не на уровне названий корпоративных систем. В ряде случаев возможны рекомендации на уровне "предпочтительного набора систем", но без навязывания конкретного выбора. Поэтому нередко, например, для автоматизации финансового управления используется один программный продукт , а расчет потребности (MRP II - задача) ведется с помощью другого. В другом филиале набор продуктов может быть другим, при тех же решаемых задачах, что оправдано, так как особенности производственного, финансового управления или логистики. как показано выше, могут быть совершенно другими. Это резко контрастирует с существующими у нас попытками автоматизировать сложные финансово-производственные структуры или даже чисто производственные холдинги с помощью одного продукта. Скорее всего проект будет неэффективен, даже если это очень совершенный продукт, но на такие средств хватает мало у кого, впрочем абсолютно универсальных продуктов в действительности не существует, особенно для производственного управления.

К сожалению в России подход, основанный на "спектре" продуктов, сталкивается с дополнительными трудностями, так как предполагает наличие (или возможность установки) на различных участках систем сравнимого класса, хотя, возможно и от разных производителей. А также большой выбор систем "одного класса" на рынке. Где же их взять?

Конечно возможны и уникальные результаты внедрения, как например, превращение компании из малозаметного производителя в одного из "хозяев" рынка. Одним из интересных вариантов такого внедрения является пример "Riverwood international", американской компании, занимающейся производством упаковочных систем. Благодаря внедрению системы управления ресурсами предприятия, ей удалось расширить свой сбыт до 20 % (с 1% !) американского рынка. В основе такого грандиозного успеха лежит описанная выше возможность управления заказами клиентов с помощью СУР.

Как же оценить целесообразность внедрения в такой неочевидной ситуации?

Ведущей точкой зрения является, с позволения сказать, "котловой" подход, основанный на признанной оценке "типичных" результатов. А именно, для компаний с годовым оборотом в диапазоне где-то от 10 до 300 миллионов долларов допустимый уровень затрат на создание ИС, включая автоматизированную систему управления - ~ 1% от годового оборота. Для компаний с большим оборотом - до 3%. Для России следует учесть, что эта оценка сделана для относительно медленно развивающихся компаний с низким средним уровнем рентабельности (по отечественным меркам) - около 10 %. При высокой динамике развития компании требования к ИС существенно возрастают, следовательно возрастают и необходимые расходы. Именно с этим связана "проблема масштаба", крайне существенная на отечественном рынке - относительно небольшие компании предъявляют весьма существенные требования к продуктам автоматизации даже финансового управления, для решения которых требуются затраты, явно несоответствующие доходам компании. И тем не менее они склонны идти на покупку. В свою очередь компании, типа крупных холдингов, имеющие (или имевшие) средства на приобретении системы склонны к затяжным "маневрам" по выбору, не осознавая, что для них проблема состоит не столько в выборе системы, сколько в наличии системы управления В то же время, компании, для которых наличие дорогостоящей системы класса MRP II - вопрос выживания, сами находятся на грани финансового выживания. Этот негативный фон весьма существенно влияет на состояние рынка ПП.

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

 

Размещение рекламы — тел. +7 495 4119920, ICQ 232284597

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

  • Проблемы экономики производства крупных программных продуктов

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

  • Клермонтский отчет об исследованиях в области баз данных

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 4119920, ICQ 232284597 Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2007 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...