Kun yksi muutos vaikuttaa moneen suunnitelmaan – voisiko tekoäly auttaa vaikutusten selvittämisessä?
Suunnittelutyössä yksittäinen muutos voi käynnistää yllättävän suuren selvitystyön.
Minulle on helpointa taustani myötä kuvitella rautatiesuunnittelussa tapahtuva muutos, esimerkiksi opastimen siirtyminen. Yhden parametrin muuttuminen voi vaikuttaa moneen muuhun.
Ensin on selvitettävä, mitä kaikkea muutos mahdollisesti koskee.
Käytännössä tämä tarkoittaa vaikutusten arvioimista, suunnitteludokumenttien välisten viittausten etsimistä ja havaintojen kirjaamista. Työ itsessään luonnollisesti vaatii asiantuntemusta, mutta osa muutokseen alussa käytettävästä ajasta kuluu etsimiseen ja kokonaisuuden muodostamiseen.
Entä jos suunnittelija saisi muutoksen perusteella alustavan vaikutuskartan automaattisesti?
Muutoksesta tarkastettavaksi työaineistoksi
Kuvitellaan työnkulku, jossa suunnittelija tallentaa uuden työnkuvauksen sovittuun kansioon.
Tämän jälkeen automaatio voisi:
- Tunnistaa muutoksen perustiedot. Se poimii työnkuvauksesta esimerkiksi kohteen, muutoksen kuvauksen ja viittaukset tarvittaviin vaatimuksiin.
- Etsiä liittyvät aineistot. Dokumenttiluettelon ja esimääritettyjen metatietojen perusteella se kokoaa liittyvät suunnitelmat ja asiakirjat.
- Koota havainnot yhteen. Jokaiselle löydökselle tallennetaan lähde sekä tieto siitä, miksi dokumentti nousi tarkasteltavaksi.
- Tuottaa alustavan vaikutuslistan. Suunnittelija saa yhteenvedon liittyvistä dokumenteista ja kysymyksistä, jotka vaativat asiantuntijan arviota.
Lopputuloksena ei olisi uusi tekninen päätös, vaan lähtökohta selvitystyölle: mitä dokumentteja muutos mahdollisesti koskee ja mitä niiden osalta pitää selvittää.
Tekoäly ei yksin ratkaise ongelmaa
Tällaisen ratkaisun keskeinen osa ei välttämättä ole kielimalli. Olennaisempaa on, miten dokumenttien väliset yhteydet tunnetaan, miten muutoksen kannalta relevantit aineistot löydetään ja miten jokainen havainto voidaan jäljittää alkuperäislähteeseen.
Tässä on myös ero tavalliseen dokumenttiavustajaan.
Dokumenttiavustaja voi tiivistää tarjouspyynnön tai työnkuvauksen ja vastata yksittäistä asiakirjaa koskeviin kysymyksiin. Työnkulku puolestaan voi yhdistää muutoksen useisiin dokumentteihin ja tuottaa niiden perusteella tarkastettavan työaineiston.
Luotettavuus edellyttää, että järjestelmä erottaa tunnetut lähtötiedot, dokumenttien väliset yhteydet ja mahdolliset vaikutukset toisistaan. Sen pitää myös tuoda esiin puuttuvat tiedot ja epävarmuudet sen sijaan, että se jättäisi mahdollisia yhteyksiä huomioimatta tai esittäisi arvauksia varmana tietona.
Suunnittelija tarkastaa alkuperäisaineiston ja päättää, mitkä vaikutukset ovat todellisia ja edellyttävät toimenpiteitä. Tämä on human-in-the-loop-ajattelun ydin: automaatio kokoaa ja jäsentää tietoa, mutta asiantuntija säilyttää päätösvallan.
Käytännön hyöty ennen raskaita integraatioita
Prototyyppiä ei tarvitse rakentaa suoraan asiakkaan dokumenttienhallintajärjestelmän tai CAD-ympäristön päälle.
Toimivuutta voidaan kokeilla pienellä esimerkkiaineistolla, joka sisältää dokumenttiluettelon, muutaman kuvitteellisen suunnitteludokumentin ja muutoksen kuvauksen. Metatietona malli saa dokumenttikohtaiset sisällönkuvaukset. Tehtävän kontekstina mallille ladataan suunnittelua ohjaavat vaatimukset. Jo tällaisella aineistolla voidaan havainnollistaa, miten dokumenttien välisiä yhteyksiä hyödynnetään ja miten havainnot esitetään suunnittelijalle.
Jos kokeilu osoittaa hyötyä, samaa työnkulkua voidaan myöhemmin laajentaa esimerkiksi dokumenttienhallinnan rajapintoihin, laajempiin aineistoihin ja muihin suunnittelun työkaluihin.
Tärkeintä on aloittaa rajatusta, todellisesta työtehtävästä eikä rakentaa ensin mahdollisimman monimutkaista tekoälyratkaisua.
Mihin teidän organisaatiossanne kuluu eniten aikaa?
Kaikki automaatiokohteet eivät ole samanarvoisia. Erityisen kiinnostavia ovat työvaiheet, joissa asiantuntijan täytyy yhdistellä tietoa useista lähteistä, selvittää riippuvuuksia tai koota toistuvasti samanlaista työaineistoa.
Vektrellä haluamme selvittää, miten tällaisia työvaiheita voitaisiin automatisoida käytännöllisesti, tietoturva huomioiden ja asiantuntijan päätösvalta säilyttäen.
Missä teillä yhden lähtötiedon muutos käynnistää eniten manuaalista selvitystyötä?
Siitä voisi löytyä hyvä ensimmäinen automaatiokohde.
When One Change Affects Multiple Designs: Could AI Help Assess the Impact?
A single change in engineering design can trigger a surprisingly large amount of investigation.
Given my background, railway engineering is the easiest context for me to use as an example. Imagine a change to the position of a railway signal. Altering just one parameter can have implications for many other parts of the design.
The first challenge is to determine what the change might affect.
In practice, this means assessing potential impacts, tracing references between design documents, and recording the findings. The engineering work itself requires expertise, of course, but some of the initial effort goes into finding relevant information and piecing together the bigger picture.
What if a designer could automatically receive a preliminary impact map based on the proposed change?
From a change request to a review-ready set of information
Imagine a workflow in which a designer saves a new change description to a designated folder.
An automated process could then:
- Identify the key details of the change. Extract information such as the affected asset, the nature of the change, and references to relevant requirements.
- Find related documents. Use a document register and predefined metadata to identify potentially relevant plans and other documents.
- Bring the findings together. Record the source of each finding and explain why a particular document has been flagged for review.
- Produce a preliminary impact list. Give the designer a summary of related documents and questions that require expert assessment.
The result would not be a new engineering decision. It would be a starting point for the investigation: which documents might be affected, and what needs to be checked in each of them?
AI alone does not solve the problem
The key component of such a solution may not be the language model itself. What matters more is how relationships between documents are represented, how relevant material is identified, and how every finding can be traced back to its original source.
This is also what distinguishes the approach from a conventional document assistant.
A document assistant can summarise a tender request or a change description and answer questions about an individual document. A workflow, by contrast, can connect a change to multiple documents and use those connections to compile information for review.
Reliability requires the system to distinguish between known input data, established relationships between documents, and potential impacts. It must also highlight missing information and uncertainty rather than overlook possible connections or present guesses as facts.
The designer reviews the original material and decides which impacts are real and require action. This is the essence of a human-in-the-loop approach: automation gathers and organises information, while the expert retains decision-making authority.
Practical value before complex integrations
A prototype does not need to be built directly on top of a customer’s document management system or CAD environment.
The concept can be tested using a small sample dataset containing a document register, a handful of fictional design documents, and a change description. The model can be provided with document-specific content descriptions as metadata, along with the requirements governing the design as context for the task.
Even this limited dataset can demonstrate how relationships between documents might be used and how findings could be presented to a designer.
If the experiment demonstrates value, the workflow can later be extended to document management interfaces, larger datasets, and other design tools.
The important thing is to start with a clearly defined, real-world task rather than building the most complex AI solution possible from the outset.
Where does your organisation spend the most time?
Not all automation opportunities are equally valuable. Particularly interesting are tasks that require experts to combine information from multiple sources, investigate dependencies, or repeatedly compile similar sets of working documents.
At Vektre, we want to explore how such tasks could be automated in a practical way, with data security in mind and expert decision-making firmly in place.
Where does a single change to an input trigger the most manual investigation in your work?
That might be a good place to start.