1

I have a BI project to be carried out using SQL Server 2008 and Cognos 8. Client seems to be using legendary adhoc/home grown applications. Where as some reports have been using an older version of Cognos. Client has no plan or what so ever as of now but in a real hurry to migrate all older version of Cognos reports to Cognos 8 (which they consider as the brand new version). Going forward Client also want to make reports available on Sharepoint with presently migrating .Net platform.

Given past exposure, I think, looking at all the underlying data/data sources required by the business users/their reports would be a better place to start, then followed by ETL, Data Warehousing to settle Database layer. That will give full performance management control over to BI platform. Where we can proceed with a prototype engaging meta data and presentation layers for a given business user object/department.

This is more of a brain-storming question that highly appreciates relevant ideas in terms of:

  • Better approach/better practice for planning a BI project on SQL Server/Cognos

  • Does it make sense to migrate old reports to new version of Cognos using IT resources or start on data sourcing/massaging with requirements gathering from business users? (as client is thinking out loud to integrate all other departments data/reporting into this BI platform in the future.) If latter is more inlined a successful project planning, how to convince the client?

  • Or should I share with the client that SQL Server 2008, specially 2012 MS BI is competent in BI, so wouldn't it be a huge cost cutting to use SQL Server/MS BI package totally instaed of mixing it with Cognos? (Client had not disclose any reason why they want to use Cognos at all)

  • Anyone who had used Cognos/SQL Server combo for BI, please provide with suggestions/tips/watch-outs/software-barriers(limits)/tips../2cents :)

4

1 回答 1

1

似乎是一个相当主观的问题，但这里有一些建议。对它们都持保留态度，因为您的情况和客户情况并非如此，并且无法在此处完全描述。

需求驱动技术选择，而不是相反。考虑可扩展性要求、可维护性（行业专业可用性和费率）等。这些是您的“能力”，请仔细考虑它们，并在需要时要求业务部门进行澄清。考虑额外或隐藏的成本/节省。SQL Server 附带分析服务、集成服务，并与 SharePoint 很好地集成。

从小处着手，然后搬出去。敏捷方法可以创造奇迹，尽管它有自己的缺陷。寻找项目发起人，即业务中可以及时满足其需求的人。提供快速、有能力和称职的解决方案。其他业务部门和用户会注意到，与仅仅试图用图表和承诺说服人们相比，你会更快、更容易地获得支持。尽快开始创造价值。

您真的不想一口气进行大规模升级。这是极其困难的，而且很可能以失败告终，至少在某种形式上是这样。查看大型公司进行的一些 SAP 实施以及随之而来的诉讼和损失（仅作为示例，不是为了获得 SAP）。

不要害怕一个多阶段的项目。在一年之内，当业务爱你的时候，从有点脱节的单个项目（这些项目都是建立在 SQL Server、SSIS、SSRS 和称职的、现代的设计之上）转移到一个统一的整体，比从多种语言、平台、架构师转移更容易以及随之而来的一系列数据问题。

于 2013-02-05T03:17:12.747 回答