聊聊软件与吃饭(二)- 谈谈甲方选择软件供应商必须要分析的几个问题

 

 

聊聊软件与吃饭(二)

 

谈谈甲方选择软件供应商必须要分析的几个问题

 

现在信息化建设成功率不高,有些原因是因为甲方在选择软件供应商前没有做自己应该做的事。很多软件厂商做项目都是前期调研、需求分析、详细设计、开发、测试、安装上线,过程都一样。甲方不要指望软件厂商的需求调研能搞清楚你的业务问题,软件厂商需求调研的时间太多,只能说明要么是你的需求你们也没说清楚,要么是软件厂商不懂业务或分析能力太差。如果你选择了一个外行的软件厂商但自己又不花时间去整理需求,想通过软件厂商所说的调研来解决问题,那项目失败就在不远处等你了。本文以请客吃饭为例来谈甲方选择软件供应商必须要分析的几个问题。如果在信息化建设项目中甲方能在选择供应商前能把这些问题仔细分析并形成一个书面的文档,那对于选择好的供应商非常有帮助。

 

背景:

我们要采购一套软件  VS  我要请几个客人吃饭

 

 

一、我们为什么要上这套软件系统(我为什么要请别人吃饭)

 

软件

吃饭

1、我们领导或上级说一定要上,我也不清楚

2、兄弟单位都上了OA系统,我们也要上

3、我们现在工作全是手工状态,无纸化办公可以提高工作效率、节约成本

4、有人免费送一套系统,不上白不上

5、我们有钱没地方花

1、我们经理说要请这几个客户吃饭

2、有个酒店新开张,说是当天吃饭全免费,所以随便叫上几个哥们去吃饭

3、客户来我公司考查,通过请吃饭可以进一步搞好客户关系

4、我中奖了,请几个朋友来吃饭庆祝一下

5、我们有钱没地方花

 

分析:

上系统和吃饭肯定都会有目标,甲方一定要做系统建设的目标分析,这个是系统建设前可行性分析的一部份,我发现大部份系统建设的可行性分析都是由软件供应商帮甲方做的。

 

二、我们有哪些人使用这套系统,他们用这套系统可以完成什么工作(有哪些人吃饭)

 

软件

吃饭

1、就我一个人用

2、我们部门人用

3、我们全公司都要用,包括总经理

1、就我一个人吃

2、几个老同学

3、某地区所有客户,大约有100人,其中有几个还是某某局的局长

 

这个分析有点像系统分析中的用例分析,首先要找出使用系统的主要人员,每个人使用这套系统可以完成什么工作,如OA系统,总经理要求可以用计算机审批,可以看到各个部门每个月的工作总结,一般员工可以用系统编制个人工作计划、查看公司工作制度、日常费用报销。很多甲方从来不做这方面的分析,最多只是个别人口头和软件供应商说一下大概情况。

 

 

三、我们需要有哪些人要参与系统的建设工作(哪些是客人,哪些是我的接待人员)

 

软件

吃饭

1、就我一个人

2、我们部门是主要建设部门,部门经理是项目组长

1、就我一个人

2、我们经理和几个市场人员也会接待

 

大部份项目甲方基本上负责系统建设的人只有系统管理员或是信息部门,认为信息化建设是系统管理员一个人的事,我们业务部门只是提要求就可以了。大家可以想一下,如果要请20个客户吃饭,里面还有一些重要客户的领导,我们只安排一个人去陪,结果会是什么样。信息化建设也是如此,如果建设一个有多个部门用的系统,系统管理员只能是协助的作用,更多工作需要是业务部门负责,比较说描述业务需求,制定业务流程,整理基础资料等等。

 

四、我的预算上限是多少(我计划使用多少钱)

 

软件

吃饭

我们预算上限是20万。

我身上总共有2000元,我计划最多使用600元。

 

大部份项目都会有一个预算的范围,有人说我们预算还不确定,那说明什么,说明你对市场基本行情不清楚,没分析过自己想要什么样的系统,自己有什么人来使用这套系统等等。如果预算不清楚的话那选择软件供应商基本上都是被忽悠的。

 

五、我们计划系统什么时间完成(我打算吃饭用多少时间)

 

软件

吃饭

我计划系统能在国庆节前上线,最迟不能过元旦。

我打算12点开始,计划1个小时吃完,最多2个小时,因为下午2点半我还有重要的会议。

 

大家都知道,项目建设时间进度很重要,那有多少甲方准确设计了自己的进度安排,有人说我的系统目标就是年前建设完成,还有的项目一般要3个月完成但甲方离谱的要求供应商2周内完成,不完成就选择其它厂商。其实信息系统建设能不能完成有很多原因是甲方问题,比如说要上系统了,甲方机房还没搞好,甲方业务流程没有理清,根据培训计划甲方参加培训的人员不能到位。

请客人吃饭也一样,比如说你预算40分钟吃完,结果你请客户去大酒店喝酒,你点菜就花了20分钟,开吃10分钟了还有几个客户没到,你说40分钟能完成吗。

 

 

 

甲方若要要求设备供应商进行有利于后期维护和问题点定位的软件系统框架设计,可从以下方面着手。 ### 明确需求标准 在项目启动前,甲方应详细且清晰地阐述软件系统的功能、性能、安全等各方面需求,同时制定设计标准规范。例如,规定系统的响应时间、并发处理能力等性能指标,以及代码编写规范、接口设计标准等。这有助于供应商理解项目目标,设计出符合要求且具备良好可维护性的框架。 ### 参设计过程 甲方可安排专业技术人员参软件系统框架设计过程中,供应商的设计团队保持密切沟通协作。在设计阶段提出意见和建议,确保框架设计充分考虑到后期维护和问题定位的便利性。比如,共同探讨系统的分层架构设计,使各层之间职责明确,便于问题隔离和定位。 ### 要求文档支持 要求供应商提供详细的设计文档,包括系统架构图、模块说明、接口文档、数据库设计文档等。这些文档应清晰地描述系统的整体结构、各模块的功能和交互方式,以及关键算法和数据流程。完备的文档能为后期维护人员提供重要的参考依据,有助于快速理解系统并定位问题。 ### 设定测试验证环节 在框架设计完成后,要求供应商进行全面的测试和验证工作,包括单元测试、集成测试、系统测试等。同时,甲方也可参部分测试工作,确保系统在不同场景下都能稳定运行,并且在出现问题时能够通过日志记录等方式快速定位问题根源。例如,要求供应商在系统中设置详细的日志记录功能,记录关键操作和异常信息。 ### 建立变更管理机制 在项目实施过程中,难免会有需求变更的情况。甲方供应商建立有效的变更管理机制,对变更进行严格的评估和控制。每次变更都应进行充分的影响分析,确保变更不会对系统的可维护性和问题定位造成负面影响。 ### 合同约束 在设备供应商签订的合同中,明确规定软件系统框架设计应满足后期维护和问题定位的要求,并约定相应的违约责任。如果供应商未能按照要求设计出便于维护和问题定位的框架,甲方有权要求其进行整改或承担相应的赔偿责任。 ```python # 以下为简单示例,模拟日志记录功能 import logging # 配置日志记录 logging.basicConfig(filename='system.log', level=logging.ERROR, format='%(asctime)s - %(levelname)s - %(message)s') try: # 模拟可能出现异常的代码 result = 1 / 0 except ZeroDivisionError as e: # 记录异常信息 logging.error(f"An error occurred: {str(e)}") ```
评论 7
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值