Transcript Yritysesittely - FORS Suomen Operaatiotutkimusseura ry

FORS-iltapäivä 2004 Optimoinnin käytännön sovelluksista
operatiivisessa suunnittelussa
Pekka Vainiomäki 18.5.2004
Consulting
Technology
Outsourcing
Copyright © 2004 Accenture All Rights Reserved. Accenture, its logo, and High Performance Delivered are trademarks of Accenture.
Taustaa…
Accenture pähkinänkuoressa:
48 maassa
> 90 000 henkilöä
Liikevaihto $ 11,8 Mrd
(31.8.2003)
Suomessa:
> 570 henkilöä
Liikevaihto € 92 Milj.
(31.8.2003)
Konsultointia, teknologiaratkaisuaja, ulkoistupalveluja…
Pekka Vainiomäki:
•
•
•
•
Matemaatikko (MSc Turusta, sovellettu matematiikka)
5 vuotta konsulttina Accenturella, Resources -toimiala
Optimointi-/suunnitteluratkaisujen toteuttamista prosessiteollisuudessa
Vetovastuu Nordic –alueella
Copyright © 2004 Accenture All Rights Reserved.
2
Esityksen sisältö
• Käytännön näkökulma konsultin silmin
– Miten teoreettiseen metodiin pohjaava lähestymistapa ja liiketoiminnalliset
tavoitteet kohtaavat
• Suunnittelujärjestelmien rakentaminen
– Mitä erityispiirteitä suunnittelujärjestelmien toteuttaminen asettaa
optimoinnille
– Käytännön haasteista projekteissa
• Esimerkki prosessiteollisuudesta
– Räätälöity leikkausoptimointiratkaisu
Copyright © 2004 Accenture All Rights Reserved.
3
Suunnittelun tasoja teollisuudessa
Lähtödata
Prosessi
Ennuste
Kapasiteetin
hallinta
Ennuste /
tilaukset
Toimitusketjun
hallinta /
tehdastaso
Yksittäiset
tilaukset
Tilaukset ja
muutokset
Tavoitteet
ja tavat
- Tuotannon / myynnin
välinen sopimus
- Skenarioiden tarkastelu
- Kapasiteetin allokointi
tuotteille
Aikaikkuna
Vuosittain,
kuukausittain
-Tarkka tuotteiden tai
reittien allokointi
- ATP / CTP
- Valmistuspaikan
optimaalinen valinta
Viikkoja
eteenpäin
Skedulointi,
tuotannon
ohjaus
-Tarkka prosessivaiheiden skedulointi tai
sekvensointi
- Esim. Rajoitepohjainen
optimointi
Päiviä
eteenpäin
Revisointi,
poikkeusten
hallinta
- Operatiivinen toimivuus
- ’Closed loop’ skedulointi
- Aikataulun / ajo-ohjelman
uudelleen optimointi,
rajoitteiden propagointi jne.
Tunteja
eteenpäin
Copyright © 2004 Accenture All Rights Reserved.
4
Operatiivinen suunnittelu
• Mitä sisältää?
– Tyypillisesti päivätasolla tehtävää suunnittelua
– Tyypillisesti monimutkaista:
•
•
•
Paljon sääntöjä tai tarpeita, jotka on pakko huomioida
Paljon toteutusvaihtoehtoja
Paljon suunnittelutapauksia (tilauksia, resursseja…)
– Suuri merkitys käyttäjälle/asiakkaalle: ohjaa keskeistä
liiketoimintaprosessia
• Esimerkkejä
– Leikkausohjelmointi tai pakkaaminen (miten lopputuotteet leikataan
tuotantomateriaalista)
– Linjojen skedulointi (tuotantolinjojen tarkka ohjaaminen)
– Logistiikka (asiakkaalle lähettäminen, reitittäminen)
– Henkilöstön allokointi (esim. vartiointiliikkeen henkilöstön
skedulointi)
Copyright © 2004 Accenture All Rights Reserved.
5
Miksi mielenkiintoista?
•
Optimoinnin soveltamista rajoittava tekijät: laskentateho ja
ratkaisualgoritmin soveltuvuus
- Laskentatehon kasvu / ’Mooren laki’
- Algoritmien ja menetelmien kehitys
=> Yhteisvaikutus: jatkuvasti paraneva hyöty/kustannus –suhde!
•
•
Mahdollista ja myös kannattavaa kehittää sopiva ratkaisija ja hankkia
tarvittava laskentakapasiteetti ennenmin kuin jatkaa suunnittelua
heikolla ohjelmistotuella. Teollisuuden parissa paljon alueita, joissa
tilaa suunnitteluratkaisuille!
Kasvavat volyymit ja markkinoiden vaatimukset pakottavat myös
automatisoimaan suunnittelua
Copyright © 2004 Accenture All Rights Reserved.
6
Toteutusprojekti
Analyysi
•
•
Mallinnus
•
Iteratiivinen
kehitys
•
Lopullinen
versio
Copyright © 2004 Accenture All Rights Reserved.
Ongelmanasettelu usein epätarkka
Ratkaisun vaatimusten määrittely
vaikeaa – järjestelmän tulevat käyttäjät
eivät matemaatikkoja…
Vanhat toimintatavat: ’Tässä
tilanteessa me on aina tehty näin’…
Iteratiivinen kehitys:
– Käyttäjien nähtävä mahdollisimman
nopeasti tulokset käytännössä
– Mahdolliset suorituskykyongelmat
kiinni aikaisessa vaiheessa
7
Lähestymistavoista
•
Pakettiratkaisu / valmisohjelmisto …
– Usein vaikea soveltaa operatiivisessa suunnittelussa. Joillakin
toimialoilla ratkaisut kuitenkin toimivia (riippuu toimialan
prosessien monimutkaisuudesta).
•
Puolivalmiste …
– Uusimmat ratkaisut hyvin lupaavia; tarpeen vaatiessa
kirjoitetaan optimointialgoritmit itse, mutta käytetään kuitenkin
valmiita komponentteja suunnittelusovelluksen muihin osiin.
Saadaan korkea mallin vastaavuus eikä tarvitse keksiä
pyörää itse.
– Quintiq, Ilog
•
Räätälöity ratkaisu …
– Voidaan rakentaa juuri haluttu malli ja algoritmi – jos osataan!
Haittapuolena koko ratkaisun rakentaminen tyhjästä; tarvitaan
kattava IT kokemus (arkkitehtuuri, käytettävyys, integraatio)
Copyright © 2004 Accenture All Rights Reserved.
8
100%:n malli suunnittelua
tukemaan?
Usein pyritään 100% tarkkaan malliin…
…käytänössä ’tarkka’ mallintaminen saattaa olla epärealistista.
1. Suunnitteluratkaisulla hallitaan jotakin toimitusketjun osaa
•
Tämän osan ulkopuoliset tekijät asettavat vaatimuksia suunnittelulle, mutta
ulkopuolisten tekijöiden mallintaminen ei käytännössä mahdollista
2. Todellisten kustannusten löytäminen
•
•
•
’Ei meillä ole sellaista tilastoitu…’
Saattaa olla vaikea määrittää jos sivuvaikutuksia esimerkiksi myöhempään
prosessiin
Joudutaan hakemaan simuloinnin kautta?
3. Kaupalliset tekijät
•
Palvelun ostaja (esim. logistiikka) toimii kaupallisia sopimuksia vastaan, ei todellisia
kustannuksia
Copyright © 2004 Accenture All Rights Reserved.
9
Ratkaisualgoritmien
soveltuvuudesta
•
•
•
•
•
Algoritmista suorituskykyä (nopeus, laatu) tärkeämpää on usein
käytännöllinen soveltuvuus suunnittelutehtävään
– Esimerkiksi: optimoinnin tulos 95% toteutuskelpoinen => 5%
korjaamiseksi myös kelvollinen osa ratkaisua purettava?
– Yksinkertainen ja osin puutteellinenkin ratkaisu voi olla hyvä, jos se
lokalisoi ongelmat ja ne voidaan hallita muutoin
Sovelluskohteet usein monimutkaisia ja vaikeita ratkaista; ”kaiken
huomioiminen” nostaa laskennallisia vaatimuksia
Haasteellisissa tilanteissa joudutaan huomiomaan myös aikataulu.
– Esimerkiksi: uusi tuotantolinja käyttöön kuukauden päästä ->
Joudutaan tekemään kompromisseja ratkaisun eleganttiuden kanssa
Algoritmien soveltuvuus ja muokattavuus
– Tehokas algoritmi esimerkiksi baseline - ongelmakirjaston kanssa…
– …mutta onko algoritmi helposti muokattavissa?
Mittari muunneltavuutta varten?
Copyright © 2004 Accenture All Rights Reserved.
10
Esimerkki 1: VasuTrim leikkausohjelmointi terästeollisuudessa
•
VasuTrim -leikkausoptimoija on Accenturen kehittämä
yhteistyössä Åbo Akademin prof. Tapio Westerlundin
kanssa.
•
Optimoija kuuluu oleellisena osana räätälöityyn
tuotannonsuunnittelujärjestelmään. Tämän VASU –
järjestelmän on kehittänyt Accenture Outokumpu
Stainless Oy:lle. Järjestelmä on käytössä Outokummun
integroidulla terästehtaalla Torniossa.
•
VasuTrim käsittelee kaikki Tornion tehtaan
asiakastilaukset ja muodostaa näiden pohjalta
sulatustilaukset. Algoritmi on ollut käytössä useita vuosia,
jolloin suunnitellun teräksen määrä on miljoonissa
tonneissa.
•
Optimoijaa käytetään sekä eräajona että interaktiivisesti
VASU –järjestelmän kautta.
Copyright © 2004 Accenture All Rights Reserved.
11
VasuTrim – ongelman asettelu
• Lähtötiedot:
– Asiakastilaukset (osarullat):
• Osarullille kiinteä leveys,
• Osarullille minimi- ja maksimipituus
• Tilauksen nominaalikoko toleranssein
• Hinta, tuoteattribuutteja (vaikuttaa sijoitteluun)
– Emorullat:
• Leveys (standardi tai vapaa minimin ja maksimin väliltä)
• Pituus (standardi tai vapaa minimin ja maksimin väliltä)
• Kustannukset per laatu, ala, tuotantovaiheet
• Ongelma:
Minimoiden: Trimmihukka, Tuotantokustannukset, Tilausten hajonta,
Leikkausasetteiden lkm, Erilaisten tuotteiden sekoittuminen samalle
emorullalle
Mikä on optimaalinen määrä emorullia, mitkä ovat näiden dimensiot, mitkä
ovat emorullien leikkausohjelmat, miten trimmihukka on jakautunut?
Copyright © 2004 Accenture All Rights Reserved.
12
Ongelman ratkaisusta
•
•
•
•
Kaksiosainen ongelma: leikkausohjelmointi ja leikattavan materiaalin
valinta (epätyypillinen leikkausongelma: emorullia ei valita varastosta
vaan niiden dimensiot päätetään optimoinnin aikana)
Epälineaarinen, NP-täydellinen ongelma.
Paljon yksittäisiä liiketoiminnallisia vaatimuksia, koska käsitellään
kaikki asiakastilaukset ja mahdolliset tuotantotilanteet
Linearisoidaan MILP:ksi Westelund et al (1996) kehittämällä
enumerointimenettelyllä
1. Pre-solve –vaihe luettelee mahdolliset asetteet ja muodostaa MILP ongelman
2. Ajetaan MILP ratkaisijan läpi
3. Muodostetaan optimoinnin tuloksesta liiketoiminnalliset entiteetit
•
•
Laskennallinen haaste: tilausten hajonnan hallinnan tarpeellisuus
havaittiin vasta myöhäisessä vaiheessa, algoritmin ollessa jo
toteutettu. Ratkaistiin uudella enumeroinnilla: enumeroidaan myös
emorullat hajannon tason mukaan.
Kaksinkertainen enumerointi kasvattaa ongelman kokoa merkittävästi
Copyright © 2004 Accenture All Rights Reserved.
13
Tulokset
• Ratkaisu:
– Joukko heuristiikkoja pre-solve vaiheessa poistaa hakuavaruudesta
varmuudella sub-optimaalisia osia
– Muuttujien priorisointi, MILP solverille ohjeita b&b puun hallintaan
– Rinnakkaislaskenta (Parallel Cplex 8.1)
– Kuormantasaus useammalle optimoijalle (4 * dual processor 2.8 GHz Intel
Xeon serverit, 1GB nopeaa muistia)
• Havaintoja…
–
–
–
–
Päivittäin optimoituja tilauksia: 1000 – 4000
Yksittäisten optimointiajojen määrä: 125 – 500
Tilauksia per ajo: tyypillisesti 5-10, maksimissaan 40
Tyypillinen optimointiaika: 1-30 s, suuret ongelmat keskeytetään 600 s
kohdalla (Tyypillisesti suurten ongelmien kohdalla valtaosa ajasta
käytetään optimaalisuuden todistamiseen)
– Vuodessa n. 150 miljoonaa riviä MILP ongelmia…
– Vastaava laskentateho reilut kymmenen vuotta sitten Intel –alustalla: noin
1000 kpl Intel 486 prosessorilla varustettua konetta…
Copyright © 2004 Accenture All Rights Reserved.
14
Yhteenveto
• Laskentatehon kasvu ja algoritmien kehitys synnyttää
jatkuvasti uusia potentiaalisia sovelluskohteita
• Ongelmien monimuotoisuus pakottaa usein räätälöityyn
ratkaisuun -> tarvitaan sekä vahvaa matemaattista
ymmärrystä että kyky käsittää liiketoiminnalliset tavoitteet
• Ratkaisualgoritmin helppo muunneltavuus erilaisiin
suunnittelutarpeisiin jopa tärkeämpää kuin suorituskyky –
liiketoiminnalliset tarpeet eivät ole staattisia vaan
muuttuvat!
• Tarpeet muunnella sovellusalgoritmeja (huomioida uusia
tarpeita) synnyttävät usein suorituskykyhaasteita, joita ei
ole alun perin voitu ennakoida.
Copyright © 2004 Accenture All Rights Reserved.
15
Kysymyksiä ???
Copyright © 2004 Accenture All Rights Reserved.
16