什么是“文件工程”?

引言

日常生活中,我们面对各式各样的文件:有购屋合同、保险合同、电信帐单、银行对帐单、劳动合同、户口文件、汽车险保单及医疗诊断... 不一而足。这类文件有个特性,就是夹杂了个人的信息或消费资料,不是通用型的文件。

企业也需要面对各式文件。除了上述为了特定客户所制作的个性化文件外、企业规范、员工劳动合同、工作手册、ISO文件、软体操作手册、飞机维修手册、半导体制程规范...等等。

企业内部无处不是文件,各个部门或单位,都在努力地制作代表其部门产出的文件。重视文件管理的企业,会投入庞大的资源来管理各单位的文件产出,以求工作品质的稳定性及企业形象的一致性。但是,绝大多数的企业,宁可投入庞大的软件资源,却不愿正视文件缺乏管理所带来的资源浪费。

在企业中最常看到的是,开发单位、生产单位、行销单位,各写各的产品开发计划,各写各的制程规范,各写各的产品说明;有人用Word来写,有人用Markdown ,也有XML或HTML。这中间是否采用共用组建?是否应该有共同规范来制约?重复的工作,在各部门一再重现;规范的样式,经由二手传递,变形了。最常见的是企业的Logo,经过几手的传递,颜色、样式都变调了。

软件在解决复杂的流程与工作,减少人力成本,减少人为的出错,加速产出;同样的,既然到处都有文件的影子,若能有效管理文件,让制作文件的人,可以协同制作,让一份文件不仅可以满足输出打印,也可以满足电子展现;甚或进一步,与其他领域的信息合并,形成一连串的电子服务。这就是我们揭诸“文件工程(Document Engineering)”的初心。

文件的展现形式

文件的展现形式,有纸面上的展现及银幕上的展现。我们姑且称纸面展现的为“实体输出”,银幕上的展现,称为“电子展现(Electronic Presentation)”。

虽说,在数字化的浪潮强袭的形势下,实体输出,逐渐退场。但是,在电子展现完全取代实体输出前,会有一段漫长的“少纸”过程。绝大多是的企业,在面对同一份文件需要实体输出,又需要电子展现时;实体输出采用专用的文件模版开发工具;而电子展现全然依赖IT的技术开发来实现。若文件的内容更新频繁,或较复杂时,两套系统要维持同步是困难重重的,维护的成本也高。纵使那天数字化程度很高,只要还有1%的人坚持收到实体文件,实体输出的系统就必须维持运行。

随着科技的发展,可以肯定的是未来文件的展现,会越来越多元。目前绝大数的人认为PDF的格式就是电子展现的唯一方式;但是,技术的发展日新月异,客户体验(User Experience)的价值越来越重要。既然采用电子展现,就应该充分利用电子展现的灵活性及互动性。未来的电子展现,应该是动态的(Dynamic)互动的(Interactive)多元的(Multi-outputs),而且是跨域的(Cross-domain)。基于此,我们可以坚信仅能呈现静态文件的PDF格式,作为现行电子文件存储及展现的标准,将难以满足市场的需求,势必很快地被打破。

What is Data-driven Document

什么是数据驱动型态(Data-driven)文件?像信用卡帐单、催缴单、保单、报表,...等,以特定对象为主的文件,都很明显是数据驱动型文件。这类型的文件,不可能采用传统文书编辑工具,一份一份的编排。因为,数量庞大,变化多,且对内容的准确性要求非常高。通常会采用特定的文件模版开发工具,设计模版,再让模版与数据结合,形成一份份个性化文件。

我们坚信未来文件个性化的需求将会越来越明显,不会仅止于上述专业的领域。我们周遭尚有许多应用可以采用数据驱动型文件的观念来实现,以提高效率及弹性。譬如:一份产品型录的制作。产品类型不多时,让美编人员采用传统编辑工具来编排,是最直接的做法;但是,碰到数量庞大,种类繁多的时候,上述采用美编人员的作法,就很明显不适用。但是,一般人碰到这样的处境时,往往不愿跳出来思考,看看有没有不一样的做法,让它更有效率。

将上述场景切换到数据驱动(Data-driven)的概念,我们可以将产品照片、产品名称、产品规格、细部说明、选项,且包含配件、价格,标签...等,规划成数据;再分开设计要展现的样式模版。模版可以设计春夏秋冬,或户外、球类、田径各式风格;产品数据也可以贴上各种类型标签。这样我们就可以根据需求,输出春季产品、夏季产品、户外活动产品、球类产品的型录。可以打印出来,也可以电子输出展现。第一次功夫,看似费力;但是,一旦建好,日后就非常弹性与方便。

企业的财务报告也是一个很典型的例子。一般财务报告的内容,依据对象不同,有粗有细。一般由财务人员采用传统的文书编辑工具来制作,依对象不同,需要制作各种版本。数据一异动,各个版本就需逐一调整。极其费工费时,且容易出错。若以数据驱动的概念来实现,数据源头是一致的,报告模版也是共用的,只是模版中植入了条件式的选择,让特定的对象,看到特定的内容。这样的做法,让财务报告的揭露更及时,更自动化。

文件处理上面临的问题

  • ➤ ︎协作问题
  • ➤ ︎版本管控问题
  • ➤ ︎触犯知识产权问题
  • ➤ ︎效率问题
  • ➤ ︎样式管理问题
  • ➤ ︎多元展现问题
  • ➤ ︎自造字管理问题
  • ➤ ︎权限问题

Why Document Engineering

推动”文件工程“这个概念的主要用意,是要解决当我们面对庞大复杂,且变动频繁又多元的文件时,如何用更好、更有效率的方式来解决。由于这类型的文件,大部分具备了,与数据结合,条件式内容,按需输出等特性,绝非一般的文书处理编辑工具可以妥善解决的。

举例来说: 一个汽车厂,生产十款不同的汽车。它可以开辟十条生产线,各自独立生产这十款车;也可以想办法将这十款车放到同一个生产线,来统一生产;可以十款车的零件都不共用;也可以将零件仔细分类,想办法让十款车的零件尽量共用。 哪一个模式才是最经济、最有效,一般人都很容易的分辨出来。这在生产制造上,是很浅显易懂的概念。

但是,将类似场景切换到企业的文件管理问题时,我们看到各部门使用的文件编排工具不尽相同;各部门制作的文件中,频繁出现类似的组建,譬如:logo、header、footer、图片...。但是,因为缺乏统一管理,展现出来的却是参差不齐的效果。这就如上述汽车厂的例子,通常我们都习惯用数种不同的工具来制作文件;我们都习于各做各的组建。所以,造成文件的展现风格不统一,人力的浪费极其庞大。

另一个挑战是-协同作业的模式。当多人同时参与一份文件的编辑时,我们都很清楚采用轮流方式:一个做完,再传递给下一位的作业模式。绝对远远不及同时编辑来的快。如何克服这样的协作模式,也是文件工程中很重要的的一环。云端协作,是解决此问题的最佳答案。云端协作,可以让编辑工具统一,零件共用,权限管理,及版本管控问题。

因此, 当文件规划与管理问题升级到企业的战略层面时,就会面临以下诸多挑战:

  • ➤ ︎如何将文件拆解成零件,并且可以共用?
  • ➤ ︎如何解决多人同时协同编辑?
  • ➤ ︎如何解决权限问题?
  • ➤ ︎如何管理数据?
  • ➤ ︎如何故管理数位资产?
  • ➤ ︎如何满足多元的输出需求?
  • ➤ ︎如何作版本的管控?
  • ➤ ︎如何作部署管理?

文件工程的核心理念

文件工程的核心理念是:

标准(Standard)与开放(Openness)

文件既然是流通的,就需要采用标准的格式,适于各种条件的展现及输出;文件既然是要协作的,就需要采用开放的工具来编辑;文件既然是要保留长久的,就需要适应各种技术及格式的更替的。

基于此,采用开放开源的模版开发工具是最基本的;在网际网路的领域中,对文件的定义与标准已经相当完整。譬如: HTML、CSS、javascript。尽量采取基于此而设计的开发工具或管理平台,更能事半功倍。而且,不用担心技术的更迭。

HTML5-CSS3-JS

样式归样式,内容归内容 —— 样式管理

这是文件工程中,很基本的理念。多年来,我们已经习于所见即所得(WYSIWYG)的编辑模式。将内容与样式绑定这么紧密,有几个问题:

  • ➤ ︎一般在创作文件时,有至少三分之一的时间,是在作编排的动作。通常内容创作者非美术编排的专业,这意味创作者花了三分之一的时间所做的编排,到发布前,很可能会被专业的美术编辑全盘推翻掉。
  • ➤ ︎同样的内容,在这个市场的阅读习惯是由左至右,由上到下;而在另一个市场,却是由上到下,由右至左。若以所见即所得的编辑方式,就会面临重新编排的困扰,耗时耗人力。

因此,如能将内容与样式设定分离。只要修改样式中的设定,即能瞬间改变文件的展现。这样可以让内容创作者更专心地投入创作。

文件零件化(Componentization)

这是一个很容易理解,但不易实现的概念。上述汽车厂的例子,已经说明得很清楚,唯有想办法,将文件零件化,让零件充分共用,才能够大量节省人力重复付出的问题。才能维持企业文件风格的一致性。

文件零件化的概念,像化学组成一样,原子(Atomics)结合成分子(Molecules),分子结合成有机体(Organisms),有机体再组合成模版(Template)

文件零件化,是一个方法论。至于在实现面,就需要一个管理机制,将这些零件管理起来。零件有版本的差异,零件有使用者。当零件更替时,要确保对每一个使用者不造成困扰。

HTML5-CSS3-JS

同源多元輸出(Single-source/Multi-channel Outputs)

文件输出方式,不外实体输出(Paper Printout),及电子展现(Electronic Presentation)。目前,电子展现与实体输出的设计与管理,多为两个平行线。亦即各用各的工具,各有各的管理机制。若遇到内容更新频繁的文件,譬如:保险条款。 要维持内容一致,就需要两套系统维持同步。这相对增加许多风险及成本。即时那天99%都电子化了,剩下1%还坚持需要实体输出,这两套系统仍得维持运转。

所以,我们认为现行的实体输出与电子展现的解决模式,不是一个好的模式。应该想办法让源头一致,依据不同的需求,提供不同的输出格式。这样才能彻底解决问题。

HTML5-CSS3-JS

动态(Dynamic)与互动(Interactive)

一般最常见的电子展现多为PDF格式。这时我们要问,在10年后,PDF还是电子文件的存储标准吗?技术的迭代,越来越快。PDF是静态展现,既然是在电子媒体展现,就应该充分利用电子媒体的灵活优势 --- 动态(Dynamic)互动(Interactive)。我们确信很快的将来,PDF的静态展现,将难以满足市场的期待。 生动活泼的动态展现,及互动机制,将让文件,不仅是文件。

电子展现(Electronic Presentation),衍生电子服务(Electronic Services)

一旦,从实体输出,切换到电子展现;电子展现又融入动态元素及互动机制。有了互动机制,文件就可以实现流程机制,衍生跨领域的电子服务

目前,电子服务多采用IT的技术来实现,成本极高;若以文件工程的角度出发,不仅可以解决文件管理问题;又同时,可以以较低的成本及更高效率的方式,来解决复杂的电子服务。

HTML5-CSS3-JS

文件工程的范畴

  • ➤ ︎样式管理(Style Managment)
  • ➤ ︎数位资产管理(Asset Managment)
  • ➤ ︎云端协作(Cloud Collaboration)
  • ➤ ︎需求管理(Requirement Management)
  • ➤ ︎版本管理(Versioning)
  • ➤ ︎认证(Authentication)与授权(Authorization)管理
  • ➤ ︎数据结合(Data Query Managment)
  • ➤ ︎服务管理(Service Managment)
  • ➤ ︎分析(Analytic)

哪些行业需要考虑导入文件工程

  • ➤ ︎需要处理数据导向文件(Data-driven Document)的行业,如保险公司、银行、证券、通信服务、健康医疗、物流、电子商务、政府...
  • ➤ ︎需要处理条件式内容(Conditional Content)的行业,如保险条款、如产品说明书、软体操作手册、航空维修手册...

保险

  • ➤ ︎对保险公司来说,需要考虑采用文件工程的模式,来解决复杂的保单个性化的问题及输出多元化问题

出版

  • ➤ ︎对文章的作者来说,用不到文件工程;但是,对出版社来说,采用文件工程的模式,可以大幅提升出版效率及简化排版编辑人力。
  • ➤ ︎采用”样式归样式,内容归内容“的观念,可以让作者专注与创作,忽略版面的编排。有效的样式管理,可以让出版业大幅提高编排的效率。

电信

  • ➤ ︎对电信公司,需要考虑采用文件工程模式,来解决复杂的帐单问题。
  • ➤ ︎作业规范,复杂且异动频繁。透过文件工程的作法可以解决知识库管理的问题。

半导体

  • ➤ ︎对半导体公司,采用文件工程模式,来解决产品规格书及复杂的制程文档管理。将产品数据化,将制程步骤零件化,充分重复使用,大幅减少管理成本。

金融

  • ➤ ︎对财务管理公司来说,需要考虑采用文件工程模式,来解决个性化财务报告的撰写问题

电商

  • ➤ ︎对大量商品销售公司来说,可以采用文件工程的方法来解决产品资讯管理(PIM, Product Information Management)问题。让产品资料数据化,让资讯单一源头。不管,产品型录的制作输出,或与电商平台的资讯同步;甚或,制作个性化产品型录,都可以快速实现。