I. Implementation Background and Core Objectives
The company is a typical small - but - excellent model. It is not large in scale, but its business chain covers "design + partial production". On the design side, it is divided into self - developed IC (R & D department) and self - developed application circuit boards (Engineering department). On the production side, most of the work is outsourced, and only simple processes such as testing, marking, and molding are retained (managed by the Engineering department).The pain points of this model are very specific. Driven by sales, customer requirements are frequently adjusted, resulting in a disconnection in information transmission among the R & D, engineering, and production departments. (For example, when a customer suddenly changes the power consumption requirements of an IC, the R & D department modifies the design but fails to synchronize it with the engineering department, and the engineering department continues to produce application boards according to the old plan.) There is also a serious disconnect between documents and implementation. There are hundreds of old - version work instructions piled up in the warehouse, but workshop employees operate based on experience. (For example, there is no fixed process for the testing procedure, and it all depends on the oral instructions of senior employees.)
The goal of promoting ISO9000 is very clear: it's not about getting a certificate, but about solving the problems of "chaotic processes and scattered implementation". What we need is a "standard that can be implemented" - for example, when sales personnel receive orders, they must clearly define the three core elements: "requirement parameters, delivery time, and quality requirements"; when R & D outputs design documents, there must be a "version number, reviewer, and transmission list"; when the engineering department conducts internal production, it must follow every step as per the "operation instructions"; when quality control inspects materials, it must use the "inspection standard sheet" to determine compliance. In a nutshell, it means that every link should "have rules to follow and evidence to refer to".
II. Implementation Plan Framework
During the Spring Festival, a complete implementation plan has been finalized. The core of the plan is divided into three phases, with each phase focusing on specific actions:
1. Preparation and Training: Thoroughly understand the current situation and assemble a good team
The first step is "system diagnosis" - using the "process mapping method" to sort out the core business of each department one by one. For example, is there any flaw in the "order review process" of the sales department? Is the "design output process" of the R & D department standardized? Is there any node control in the "outsourced production connection process" of the engineering department? The diagnosis method is very practical - communicating with the heads of each department "whenever possible" (10 minutes during the morning meeting and 15 minutes before getting off work). Since everyone is busy, we can only use fragmented time to fully understand the real pain points.
Define the process: First, clarify the core business chains of each department (for example, "Sales receive orders → R & D conducts IC design → Engineering conducts application board design → Outsourced production → Internal testing → Quality control inspection → Shipment").
Sub - processes: Split the process into categories such as "Customer demand identification, Design and development, Production control, Supplier management". For each process, clarify "Input (e.g., customer demand), Output (e.g., design documents), Responsible department (e.g., R & D)".
Compile the manual: The quality manual is the "system outline", which clarifies the company's quality policy (for example, "Centering on customer needs and ensuring quality with standard processes") and the responsibilities of each department.
Entire program documents: such as "Order Review Procedure", "Design Change Procedure", and "Supplier Management Procedure". These are the "frameworks of processes", specifying "who should do it, how to do it, and how long it takes".
Revise the third-level documents: namely work instructions, such as "IC design work instruction" and "testing process work instruction". These are the "operational details", and it is necessary to clearly state "what tools to use, what steps to follow, and what issues to pay attention to".
Compile Level 4 forms: For example, "Order Review Form", "Design Change Notice", "Inspection Record Form". These are "evidence of the process", and it is necessary to record "what was done, who did it, and when it was done".
Finalized version release: All documents must be "reviewed by the department head and approved by the general manager". After the release, all old - version documents shall be retrieved to avoid confusion.
III. Progress of current situation diagnosis
The systematic diagnosis was launched in February, and currently, two key conclusions have been clarified:
1. Organizational Structure and Core Responsibilities
The company has 7 core departments with very clear responsibility boundaries:
Market sales: Receive customer requirements at the front end and output the "Order Requirement Form".
Research and Development: Responsible for IC design and outputting "IC design drawings and technical specifications".
Project: Two major responsibilities – Firstly, apply circuit board design (in accordance with IC technical specifications); secondly, conduct simple in - house production (testing, marking, and molding).
Quality control: Currently responsible for "incoming inspection (materials supplied by suppliers) and outgoing inspection (finished products)". In the future, "supplier management" (such as supplier evaluation and follow - up on rectification of quality issues) will be added.
Operations: Coordinate the connection between outsourced production, in-house production, and the supply chain.
Personnel administration: Responsible for logistics and training.
Finance: Control costs and funds.
2. Preliminary identification of business pain points
The core problems identified in the diagnosis are concentrated in three aspects:
Design stage: The IC design documentation output by R & D lacks "version control". For example, after three design modifications, there is no labeling of "V1.0/V2.0/V3.0", which causes the engineering team to repeatedly confirm "Is this the latest version?" when making application boards.
Production stage: The Engineering Department is responsible for both the design of application boards and the management of internal production, which disperses its energy. For example, when the design tasks are urgent, the internal testing process will be "streamlined", resulting in quality fluctuations.
Quality control process: Currently, only "result inspection" is carried out (for example, materials are accepted if they pass the inspection), and there is no "process management" (for example, when the soldering defect rate of a supplier is high, there is no fixed process for follow - up rectification). In the future, "supplier management" must be included in the responsibilities of quality control, and actions should be standardized using "supplier evaluation forms" and "quality rectification notice forms".
IV. Future Directions for Advancement
The next key point is to "transform the diagnosis results into processes". For example, regarding "design version management", a "design document version control procedure" should be added in the R & D department, specifying that "the version number must be updated every time a change is made and synchronized with the engineering and quality control departments". Regarding "scattered engineering energy", the work instructions for "internal production" should be refined so that new employees can also follow the processes, reducing their dependence on senior employees. Regarding "supplier management", a "supplier evaluation process" and a "quality rectification tracking process" should be added in the quality control department, and a form should be used to record every problem and rectification result of the suppliers.
In a nutshell, the logic behind our implementation of ISO9000 is quite simple: First, sort out the "chaotic processes"; second, document the "clarified processes"; and finally, ensure the "documented processes" are put into practice. It's not for the sake of passing the certification, but for streamlining our own business operations.