Форум
Читайте нас также:

об электронной торговле - для интернет-магазинов и ритейла. портал и сообщество

Форум

Content Management System - что мы под этим понимаем?



Ссылка на сообщение


Уважаемые со-форумники!



Я тут озадачилась вопросом :



"А что конкретно мы понимаем под термином Content Management System ?"



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



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



Для себя я раздробила этот вопрос на подвопросы:



1)Есть ли твердый перечень того функционала, который должен входить в систему?



2)Должен ли быть управляемым дизайн системы или это привилегия разработчиков?



3)Web-интерфейс доступа или некий "клиент"? (напр. для нашей системы клиентом является Lotus Notes R5)



4)Как быть с кросс-платформенностью? (напр. у нас сервером обязательно должен быть Domino R5, а в случае если система целиком и полностью написана на Java, вопросы плаформы отпадают)



5)Какие могут быть критерии безопасности системы - извне и внутри?



6)Насколько глубоко следует итегрировать систему с прочими бизнес-процессами клиента?



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



8)Какие гарантии должен получить заказчик?



9)Что оптимальней - продавать систему целиком или только некое "ядро" с дополнительными модулями?



Надеюсь на интересное обсуждение!



Возможно перечень вопросов следует расширить?! Ваши предложения - ?



С уважением, Виктория.



Ссылка на сообщение


Я занимаюсь разработкой интернет магазинов и мне тоже интересен вопрос про функционал программы управления интернет-магазином.

Я для себя вот как представляю

ответы на представленные вопросы:



1.Перечня нет. Чем больше тем лучше. Наращивая функции своего магазина, я расширяю круг потенциальных клиентов.



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



3.Некий "клеент" или web? Укаждого метода есть свои достоинства и недостатки. Для удаленки удобнее web, для работы из оффиса "клиент"



4.Если программа-клиент управления работает через web, то задумыватся над кросплатформенностью нет необходимости, а сервер стоит выбирать по задачам и средствам. Под задачи задачи ЛЮБОГО интернет магазина достаточно и MySQL.



5. ----

6. ----



7. Интергация с другими приложениями клиента? А вы знаете с какими. Это может быть 1С, BEST , своя разработка вообщем что угодно.

Интегрировать за разумное время и цену практически не реально.



8. Почитайте лицензию от Microsoft ......!!! Более грамотного отмаза от каких бы то нибыло обязательств и гарантий я не видел. Так что это от вас зависит.



9. Кому вы собираетесь продавать, некое "ядро". Директору компании который не бум-бум в этом? Что он будет с ним делать? Программист который сможет довести ваше ядро до ума, вероятно и сам сможет написать что-то подобное. Вариант на мой взгляд - предлагать готоваое решение под ключ. Что я и делаю относительно интернет магазина.



Ссылка на сообщение


shoponline, спасибо за ответ!



Интегрировать за разумное время и цену практически не реально. >> Ну здесь я бы поспорила ))) Есть опыт интеграции Инет-магазина(Ява/Оракл) с 1С:Склад - вполне реально. Тут ключевым являлется только цена)))



Почитайте лицензию от Microsoft ......!!! >> Читала, знаю, но тем не менее заказчики требуют включать определенные санкции в договора, хотелось бы понять насколько можно прогибаться, что гарантировать и т.д.



Кому вы собираетесь продавать, некое "ядро". >> Под ядром я подразумевала НЕ ДВИЖОК, а некий готовый модуль, например, интернет-магазин))), а к нему предлагать некие "бантики" типа "аукцион", "рассылка", "публикации" и т.д. Т.е. решение в любом случае будет под ключ, но в "обрезанном виде". Или интереснее все в одном? (естесственно, определенный уровень кастомизации под заказчика учитывается).



Ссылка на сообщение


Ну вот только с 1С интегрировать и можно ...:-)

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



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



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



Ссылка на сообщение


Добавлю по поводу совместимости.



Я бы поставил вопрос так: система должна поддерживать _стандартные_ и признанные форматы обмена данными. Например уметь гибко работать с XML.

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



Ссылка на сообщение


AntonM, спасибо за ответ!



Полностью с вами согласна.



К сожалению, проблемы чаще всего упираются не в собственную разработку, а в софт заказчика, который:

а) не обновлял версии с 9.. года

б) купил хрякнутый диск на Горбушке

с) получил программу бухучета от собственного сынульки, написавшего эту программу как зачет по информатике



С ними как дружить?! ;)



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



Ссылка на сообщение


2 Виктория



По поводу "дружбы":

Я таки не пытаюсь с ними "дружить", т.к. это тупиковый путь развития. Естественно разок-другой объясню заказчику весь спектр проблем продолжения работы с необновляемым, неподдерживаемым и т.п. ПО.

Те, кто понял, в чем суть этих "граблей" - сами стремятся к переходу на нормальные, стандартизированные "рельсы". А если люди не понимают, что из-за вполне вероятного глюка на_колене_сделанной программы они могут потерять намного больше чем стоит лицензированное ПО..., то зачем мне их проблемы!? :-)



По поводу "что такое CMS", какова функциональность, интерфейс и т.п. у меня такое видение:

CMS - это общее название целого ряда ПО. Ну как "Графический редактор"... которыми являются и Photoshop c лицензией ~$800 и поставляемый с виндами Paint... Функциональность, стоимость и назначение у них разное. То же самое и с CMS, основной признак которых позволять управлять содержанием. Как управлять, насколько удобно, насколько полно и т.п. это уже вопрос конкретной реализации.

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



О требованиях к CMS. По мне так все сказано в русском переводе СМS - она должна управлять контентом. При этом не надо путать с конструкторами сайтов. Т.е. для CMS должно быть пофиг что на ней будут делать - сайт визитку, портал, магазин, внутреннюю систему управления бизнесом и пр. А как только всплывают слова "модуль новостной ленты", "модуль интернет магазина" - все, это конструктор сайтов. И еще важный пункт. CMS должна работать со стандартами (какими это отдельный вопрос). Т.е. импорт-экспорт данных с помощью стандартных форматов. Ведение разработок на основе CMS должно вестись "стандартными" специалистами. Т.е. термина типа "програмист 1C" не должно появляться.



О интерфейсе. Чем удобнее, гибче и т.п. тем лучше :-) Может быть веб-интерфейс, может быть "клиент", может быть и то и то....



Ссылка на сообщение


Расширяю предложения.

А посмотреть то можно, где Ваш CMS, о чем вообще разгоор идет.

Что продаете то?

И как насчет Виктории, она прилагается к CMS или нет?

Дадим 500 баксов за умный ответ.



Ссылка на сообщение


AntonM!



Спасибо большое за ответ!



Была в командировке, поэтому такая задержка ))



В общем и целом согласна, единственное, не совсем поняла по поводу контруктора и менеджера.



Мне кажется, это принципиально разные вещи.



Во втором случае это идеология CMS, а в первом - его практическая реализация.



Понятно, что сам "движок" в утрированном варианте действует для любого модуля одинаково "получил - опубликовал - вернул на редакцию - опубликовал - удалил" (это я сильно грубо;)), но тем у каждого модуля свой формат (если так понятнее, свой XML), что требует определенной кастомизации, и вопрос заключался в том, нужно ли продавать клиенту в рамках своего CMS дополнительные функции, которые ему, пока(фактор "пока" тоже вопрос%)) не нужны?



Возможно, немного запутанно, но надеюсь, поймете.



Еще раз спасибо за интересный ответ!



Ссылка на сообщение


Green!



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



Ответ на второй вопрос:



Виктория прилагается к CMS на этапе кастомизации, внедрения и пилотной эксплуатации в качестве разработчика.



В любом случае, 500 баксов оставьте себе. Рекомендую применить их на общеинтеллектуальное развитие и более презентабельный домен.






Ответить


Форум закрыт. Написание сообщений ограничено





2001 - 2018 © Оборот.ру. Все права защищены