现状流程图
清晰呈现一个流程如今实际是如何运行的,包括员工使用、但没有人记录下来的各种变通做法。
企业迪拜聘请业务系统分析师,是希望在业务问题与真正负责搭建修复方案的人之间架起一座桥梁。销售经理说 CRM “让所有人的工作都变慢了”,财务负责人说核对 ERP 数据要花三天时间,而这本不应该花这么久,这两种说法对开发工程师来说都不够具体,无法据此行动。分析师的工作,就是把这类抱怨转化为一份书面需求:当前流程究竟是什么样,问题出在哪里,新流程需要做到什么,以及如何判断它是否真的有效。
这刻意不是一个编码角色。业务系统分析师会访谈每天使用系统的人,梳理流程真实运行的方式,而不是组织架构图上应该运行的方式,并记录两者之间的差距。这份文档随后就成为衡量开发工程师、平台顾问,乃至整个项目的简报,这也是为什么开局分析工作不到位,无论开发工程师多么优秀,往往都会在后期产生一次代价高昂、方向错误的搭建。
这一角色的交付内容
书面成果,而不只是会议记录。
清晰呈现一个流程如今实际是如何运行的,包括员工使用、但没有人记录下来的各种变通做法。
说明一个新系统或变更后的系统必须做到什么的具体、可测试的陈述,区别于“让它更快”这类含糊的目标。
就不同部门各自假设的流程应该是什么样,在开发开始之前、而不是在开发过程中,给出一个已经化解的答案。
清楚说明当前系统或流程在哪些方面无法满足业务需求,并按影响程度排序。
对照原始需求核查交付系统的场景,与真实业务用户一起运行,而不只是由开发团队自行核查。
说明员工层面需要改变什么,而不只是系统层面,让一次技术上正确的上线,不会因为无人真正采用而失败。
值得关注的技能
迪拜企业在聘请业务系统分析师之前应核查的是分析的严谨性和平实的文字表达,而不是某一款具体工具的熟练程度。
| 技能或领域 | 合格的表现 | 为何重要 |
|---|---|---|
| 需求撰写 | 撰写具体、可测试的需求,而不是开发工程师无法据以行动的空泛愿景 | 一份含糊的需求,会产出一个技术上完成交付、但结果依然错误的系统 |
| 流程梳理 | 按流程实际运行的方式绘制流程图,揭示变通做法,而不只是记录官方规定的流程 | 只围绕官方流程设计而忽视真实流程,会让新系统同样面临被绕开的风险 |
| 利益相关方访谈 | 提出能及早揭示分歧的问题,而不是任由每个人都以为大家意见一致 | 部门之间未解决的分歧,是项目中途范围蔓延的常见原因 |
| 行业熟悉度 | 对 ERP 或 CRM 这类相关系统有足够的了解,能写出切合实际的需求 | 不熟悉平台的分析师,可能写出系统实际无法支持的需求 |
| 平实的文字表达 | 撰写的文档,非技术相关方和开发工程师都能读懂,无需翻译 | 只有分析师本人能理解的需求,等于没有完成它唯一的任务 |
国际商业分析协会把这一资深层级的工作定义为统筹需求,并对交付结果是否真正满足组织的实际需要负责,这对这一级别的候选人来说是一个公允的考核标准。
合作方式
顾问咨询是最自然的合作方式:一项界定清晰的分析工作,例如为一次 ERP 替换梳理需求,或对一个失效的流程进行梳理,在任何人承诺开发之前,以书面成果的形式交付。项目制适合将分析与交付结合在一起,同一次合作从需求梳理一直延续到系统上线。招聘支持适合希望把分析师长期留在自己团队、尤其是每年运行多个系统项目的企业。专职安排适合规模足够大、能持续让一名分析师在一系列持续变更项目中保持忙碌的组织。
候选人评估
能揭示迪拜的业务系统分析师是否具备真正分析判断力、而不只是善于组织会议的核查方式。
阅读它的清晰度和可测试性。一份用正式语言包装起来的含糊需求,是一个不好的信号。
每一个真实项目都会遇到这种情况。他们的处理方式,远比流程图模板更能说明问题。
询问优先级最低的差距后来怎么处理了,因为一个人如何分级,与他发现了什么同样重要。
描述一个来自您企业、真实而杂乱的问题,看看他们在动笔之前会提出哪些问题。
有真实经验的候选人能描述一个遗漏了某些内容的需求,以及它是如何被发现的,而不是声称自己从未出过错。
认证
在迪拜,有一个机构为业务系统分析师制定了多个经验层级的标准。
根据其官方认证页面,国际商业分析协会颁发一套分级凭证,从入门级证书一直到 CBAP,其最高级凭证要求多年可查证的经验,并需通过一场基于情境的考试。
CBAP 或同等凭证证明候选人接受过系统化的分析方法训练。它本身并不能证明候选人熟悉您具体的 ERP 或 CRM 平台,这一点值得根据您项目实际涉及的系统单独核实。
阿联酋相关事项
业务系统分析师应纳入需求的两个方面。
凡项目涉及客户或员工的个人数据,需求文档应明确写出为满足阿联酋数据保护法律《2021 年第 45 号联邦法令》所需的各项控制措施,而不是留到开发过程中再去解决。
如果系统将同时以阿拉伯语和英语使用,需求和测试脚本应明确说明这一点,因为从书面需求阶段设计从右到左的支持,远比在交付后再补做要简单得多。
直接解答
不是。项目经理跟踪时间、成本和交付进度。业务系统分析师则要厘清究竟应该搭建什么、按什么顺序、为什么这样做,并把这些写成一份规格说明书。较大的项目往往两者都需要,并紧密协作。
对于一个真正很小、需求清晰的变更,一位优秀的顾问通常可以直接收集所需信息。当一项变更涉及不止一个部门、不止一个系统,或利益相关方对当前流程本身的看法都不一致时,分析工作才真正显现价值。
一般不会。产出的是一份需求、一张流程图或一份规格说明书,随后由开发工程师、顾问或平台团队据此搭建。部分分析师具备足够的技术背景,能自行配置一些简单设置,但编码并不是这一角色的核心。
可以,这是简报中常见的一部分,因为撰写需求的分析师最适合核查交付的系统是否真正满足需求,并与日常使用系统的业务用户一起完成核查。
这正是分析工作要在开发开始前,通过结构化访谈和流程梳理来揭示并化解的问题,而不是留到开发进行到一半时才被发现。
资料来源
书面固定价格
已收到,我们正在为您撰写报价。
工作时间内您将在 45 分钟内收到。请查收确认邮件。