蔡学镛：写SOP（标准作业程序）就是写程序
任何一家有制度的公司，都会定义「标准作业程序」（Standard Operating Procedure，SOP）。对麦当劳和统一企业等以服务见长的大企业来说，SOP是重要资产、公司经营的Know-How，影响产品与服务质量，只要SOP完备，就可以快速展店。
甚至，日前警方查获的诈骗集团也有SOP，该集团将诈骗手法详细记载成为诈骗执行手册。当诈骗集团也懂得蓝海策略（诈骗手法推陈出新）、知道长尾效应（对准特定小众族群进行诈骗也能获利），并充分运用SOP时，或许也正代表我们社会相当进步，已经进入所谓的知识经济的时代吧。
一般公司内部的运作，处处仰赖SOP。有的公司虽小，但SOP累积多年之后也是厚厚一大本。一般来说，SOP会告诉人员，要怎么做一件工作、处理一件事情、调用公司的资源……等。
这一切，是不是让热爱程序的你有所联想？
把公司看成一个计算机系统，有许多的资源（设备、材料、人员、线程、I/O），每个员工都是一个线程，柜台和仓储是I/O，负责数据 的进出，其中，SOP扮演程序的角色，以有效的方式协调、处理、运用这些资源，以达到特定的目的。
如果SOP是在公司内执行的程序，那么，写SOP其实就是写程序，写程序的方法自然也可以套用在SOP撰写上。写程序的经验，对于写SOP，其实是有帮助的。当你需要写SOP，却不知从何下手时，不妨往程序设计的方向来思考。
我认为SOP可以分成三大部分，第一部分是常规作业（Routine），第二部分是事件驱动（Event-Driven）作业，第三部分是例外处理（Exception Handling）。如果你了解程序设计，这三者该写些什么，你应该就会知道。
一个好的SOP应该具备哪些要素？从判断程序的准则来看，应该是：执行效率高且耗费资源少、容易理解、支持跨平台（在不同的分店一体适用）、方便修改维护。
既然SOP是一种程序，那么，也可以采用不同的编程思维（Paradigm），例如面向对象、命令式、逻辑式、函数式。许多时候，用文字叙述的SOP，往往不够清楚，如果能够改用写程序的方式来表达（不使用真正的编程语言，而是使用Pseudo Code），搭配批注，也会是不错的方式。
除了可以套用程序设计思维，写SOP时也可以套用软件工程的作法。或许SOP比较适合采用敏捷（Agile）与反复式（Iterative）的开发方式。因为SOP在执行之后才会发现缺失，就可以继续进行修正补强。别忘了每次的改变，记得要做好版本控制。
UML（Unified Modeling Language，统一塑模语言）支持许多种图，几乎每一种图都可以在SOP内派上用场。UML可以帮助SOP作者编写SOP，也可以帮助读者理解SOP。
和程序设计一样，写SOP不能光靠语言和逻辑，还需要特定专业领域的知识。
例如，写3D绘图的程序，必须先了解3D图学的许多知识。对于SOP来说，专业领域可能是会计、税务、法律……等。所以编写SOP时，最好与了解该领域的人一同合作。
OO的封装和继承也可以套用在SOP，利用封装将资源和动作集中在一起，利用继承将某些方法进行扩充或修改（例如「同A作业，但步骤3更改如下」）。但是OO的多型似乎不可能用在SOP上，所以还是得大量使用switch/case的语法。
另外，逻辑式编程的作法似乎相当适合用在SOP，因为大部分的人都有足够的逻辑能力，可以理解与判断。使用逻辑编程可以让SOP的编写较简洁。当一个资源许多人抢着用时，你就可以引进Concurrency编程的方法。
写程序时，我们要多使用变量，而不是将数据写死在程序代码中，写SOP也是一样，例如，你不应该在SOP内写「把这份数据交给陈水扁」，而是应该写「把这份数据交给总统」。毕竟，陈水扁总有下台的一天。
有许多程序工具可以帮助我们检查程序中的语法／语义错误、Dead Code，甚至Dead Lock、效能瓶颈。但是SOP却没有这样的检查工具，一切只能靠SOP编写者的经验。
所幸，人和程序不一样，人是有弹性的，许多SOP的缺失可能会因为人的介入，能视情况应变而不会发生问题。但是，好的SOP并不能保证公司营运不会出问题，许多公共安全意外发生的原因，是检修人员偷懒，没有确实按照SOP规定的步骤进行维修所造成。
因此，虽然写SOP与写程序相似，但两者终究不同，SOP的执行者是人，不是机器。所以写SOP时，一定要充分考虑到人的因素，纳入人的弹性，排除人的偷懒（或自作聪明），才会写出真正实用的SOP。
作者简介：
蔡学镛－技术顾问
清华大学资讯工程硕士，曾任华硕集团软件工程师、元智大学信息系讲师、美商欧莱礼出版社技术编辑、台湾微软特约专栏作家
http://news.csdn.net/n/20080109/112558.html
甚至，日前警方查获的诈骗集团也有SOP，该集团将诈骗手法详细记载成为诈骗执行手册。当诈骗集团也懂得蓝海策略（诈骗手法推陈出新）、知道长尾效应（对准特定小众族群进行诈骗也能获利），并充分运用SOP时，或许也正代表我们社会相当进步，已经进入所谓的知识经济的时代吧。
一般公司内部的运作，处处仰赖SOP。有的公司虽小，但SOP累积多年之后也是厚厚一大本。一般来说，SOP会告诉人员，要怎么做一件工作、处理一件事情、调用公司的资源……等。
这一切，是不是让热爱程序的你有所联想？
把公司看成一个计算机系统，有许多的资源（设备、材料、人员、线程、I/O），每个员工都是一个线程，柜台和仓储是I/O，负责
如果SOP是在公司内执行的程序，那么，写SOP其实就是写程序，写程序的方法自然也可以套用在SOP撰写上。写程序的经验，对于写SOP，其实是有帮助的。当你需要写SOP，却不知从何下手时，不妨往程序设计的方向来思考。
我认为SOP可以分成三大部分，第一部分是常规作业（Routine），第二部分是事件驱动（Event-Driven）作业，第三部分是例外处理（Exception Handling）。如果你了解程序设计，这三者该写些什么，你应该就会知道。
一个好的SOP应该具备哪些要素？从判断程序的准则来看，应该是：执行效率高且耗费资源少、容易理解、支持跨平台（在不同的分店一体适用）、方便修改维护。
既然SOP是一种程序，那么，也可以采用不同的编程思维（Paradigm），例如面向对象、命令式、逻辑式、函数式。许多时候，用文字叙述的SOP，往往不够清楚，如果能够改用写程序的方式来表达（不使用真正的编程语言，而是使用Pseudo Code），搭配批注，也会是不错的方式。
除了可以套用程序设计思维，写SOP时也可以套用软件工程的作法。或许SOP比较适合采用敏捷（Agile）与反复式（Iterative）的开发方式。因为SOP在执行之后才会发现缺失，就可以继续进行修正补强。别忘了每次的改变，记得要做好版本控制。
UML（Unified Modeling Language，统一塑模语言）支持许多种图，几乎每一种图都可以在SOP内派上用场。UML可以帮助SOP作者编写SOP，也可以帮助读者理解SOP。
和程序设计一样，写SOP不能光靠语言和逻辑，还需要特定专业领域的知识。
例如，写3D绘图的程序，必须先了解3D图学的许多知识。对于SOP来说，专业领域可能是会计、税务、法律……等。所以编写SOP时，最好与了解该领域的人一同合作。
OO的封装和继承也可以套用在SOP，利用封装将资源和动作集中在一起，利用继承将某些方法进行扩充或修改（例如「同A作业，但步骤3更改如下」）。但是OO的多型似乎不可能用在SOP上，所以还是得大量使用switch/case的语法。
另外，逻辑式编程的作法似乎相当适合用在SOP，因为大部分的人都有足够的逻辑能力，可以理解与判断。使用逻辑编程可以让SOP的编写较简洁。当一个资源许多人抢着用时，你就可以引进Concurrency编程的方法。
写程序时，我们要多使用变量，而不是将数据写死在程序代码中，写SOP也是一样，例如，你不应该在SOP内写「把这份数据交给陈水扁」，而是应该写「把这份数据交给总统」。毕竟，陈水扁总有下台的一天。
有许多程序工具可以帮助我们检查程序中的语法／语义错误、Dead Code，甚至Dead Lock、效能瓶颈。但是SOP却没有这样的检查工具，一切只能靠SOP编写者的经验。
所幸，人和程序不一样，人是有弹性的，许多SOP的缺失可能会因为人的介入，能视情况应变而不会发生问题。但是，好的SOP并不能保证公司营运不会出问题，许多公共安全意外发生的原因，是检修人员偷懒，没有确实按照SOP规定的步骤进行维修所造成。
因此，虽然写SOP与写程序相似，但两者终究不同，SOP的执行者是人，不是机器。所以写SOP时，一定要充分考虑到人的因素，纳入人的弹性，排除人的偷懒（或自作聪明），才会写出真正实用的SOP。
作者简介：
蔡学镛－技术顾问
清华大学资讯工程硕士，曾任华硕集团软件工程师、元智大学信息系讲师、美商欧莱礼出版社技术编辑、台湾微软特约专栏作家
http://news.csdn.net/n/20080109/112558.html
